On Sat, Jul 28, 2001 at 10:06:43PM +0100, Philip Blundell wrote:
> >The "extern" was only an escape for the case that the compiler cannot
> >inline the function. Due to the fact, that current gcc has "static
> >inline" it is better to use this, because with "static inline" we do
> >not need to keep a global symbol just for the case the compiler is not
> >capable to inline the function in some place.
>
> The versions in the .c file are there so that the "ops" structure can point to
> them. The ones in the .h file are purely an optimisation to allow you to
> short-circuit the ops struct if you know only one driver is involved.
Because of that the compiler has to create a "real" function from the
code anyway. The way this is handled by gcc is stated in the gcc info
pages:
"When a function is both inline and `static', if all calls to the
function are integrated into the caller, and the function's
address is never used, then the function's own assembler code is
never referenced. In this case, GNU CC does not actually output
assembler code for the function, unless you specify the option
`-fkeep-inline-functions'. Some calls cannot be integrated for
various reasons (in particular, calls that precede the function's
definition cannot be integrated, and neither can recursive calls
within the definition). If there is a nonintegrated call, then
the function is compiled to assembler code as usual. The function
must also be compiled as usual if the program refers to its
address, because that can't be inlined."
>
> Changing this stuff to "static inline" still offends my sense of aesthetics
> somewhat, but I guess it's okay if you have checked that it still does the
> right thing in the CONFIG_PARPORT_OTHER case.
I didn't test this before your mail. But to be absolutely sure, I
tested it now. --- And it works perfectly.
Robert
-- Robert Schiele mailto:rschiele@uni-mannheim.de Tel./Fax: +49-621-10059 http://webrum.uni-mannheim.de/math/rschiele/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:39 EST