Re: Guidance please: static or extern __inline__

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Kean Johnston <jkj@sco.com> 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