Re: Guidance please: static or extern __inline__

[Kean Johnston <jkj at sco dot com>]

> [ 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
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.

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".

Kean