Kean Johnston <[EMAIL PROTECTED]> writes:
| > [ cough ] "always_inline" [ cough ]
| HA!
|
| I *knew* there was a solution. Thank you Mike.
|
| So now I guess the question remains, for the cases where
| you want a function to behave differently depending on
| pre-processor conditionals, whats the best way of doing
| it? The particularly interesting case is with LFS stuff:
|
| extern int open (const char *, int, int); /* Legacy */
| extern int __open (const char *, int, int); /* New */
| extern int open32 (const char *, int, int); /* New LFS */
| extern int open64 (const char *, int, int); /* New LFS */
|
| #if _FILE_OFFSET_BITS - 0 == 32
| #define open open32
| #elif _FILE_OFFSET_BITS - 0 == 64
| #define open open64
| #else
| #define open __open
| #endif
|
| Wreaks havoc with libstdc++ and libjava, where class
| members are called 'open'. I would ideally want those calls
yes, you really don't want tp play Cpp games there :-)
| defined in terms of inline, and leave the pre-processor
| out of it. For argument's sake, lets assume open wasn't
| actualy variadic and that it was declared as above. Would
| the best thing to have in the header file be:
|
| #if _FILE_OFFSET_BITS - 0 == 32
| static __inline__ int open (const char *__1, int __2, int __3)
| {
| return open32(__1, __2, __3);
| }
| #endif
|
| -or-
|
| #if _FILE_OFFSET_BITS - 0 == 32
| extern __inline__ __attribute__ ((__always_inline__))
| int open (const char *__1, int __2, int __3)
| {
| return open32(__1, __2, __3);
| }
| #endif
|
| I fully understand Daniel's point about why you *dont* want
| &open to really return the address of the old open, but you
| may also want &open to be consistent across different
| modules. With the static inline case, they won't be. The case
| where that sort of shenanigans is refering to old API's is
| of course the worst case. However, for other simpler cases,
| lets say, min or max, you may well have a version in libc,
| for linkage purposes, but under normal circumstances you
| would like it to be inlined. &min would be the same always,
| but in cases where you are not taking the address of the
| function, and are just using it, you want the quicker, inlined
| version to save on a call to libc.
So, can I summarize your question as a way of trying to make "open"
and alias for open32 or open63 and not having to get into the trap of
different function address? If yes, does glibc's weak_alias would
work for you without creating new problems?
| I'm trying to solve a problem not create one, and I get the
| feeling that using static inline will solve more problems,
| but I am at war with the pedant in me that says the extern
| inline case may be more "purely correct".
I can understand that :-)
-- Gaby
