Is everybody an idiot today??

[cjsmith]

For the C/C++ geeks out there, here's a grumpymaking thing I stumbled upon today.

In a .h file:

void __inline FUNCTION_NAME(mystruct* foo)
{
   foo->addrValid = TRUE; 
}

And therefore, in my .c file:

// HORRIBLE HACK!  Only one .o in an executable can have StupidInclude.h included.
// It defines inline functions and the link step will fail if multiple .o files
// contain those definitions.  But every .o in this type of executable must have the
// app data structure definition... which, for this app, relies on StupidInclude.h.
// Therefore, there can be only one .o in this executable.
#include "echoer.c"
#include "listener.c"
#include "pinger.c"

I know there are ways around this, potentially involving (say) precompiled headers, but this is supposedly a simple proof-of-concept app so I'm not bothering for now. And seriously. Who would release something like that and not get fired? Never mind; I know the answer.

Comments

[brooksmoses]

It's also possible that this is related to the inline weirdness in GCC (if that's the "doesn't cost over $1000" compiler). GCC defined the __inline keyword before C99 standardized "inline", and the semantics are subtly different (and, iirc, though my recollection is very hazy, this is one of the places where that's true), and I think that the more recent versions of GCC have changed the definition to match the C99 standard.

If that's true, there are compiler flags to use the "other" behavior which may be relevant. It is also possible that a "#define __inline SOMETHING" hack before including the relevant header files will make things work.

Oh, wait a minute. Right. I decided to check and see how we handle this in our libraries, and realized that this is a stupidity on the part of those library developers -- for this to work right, that function needs to be declared static as well as __inline. A rough hunch is that "#define __inline static __inline" will do the right thing, though that's an ugly hack that breaks if __inline is already a preprocessor macro. (Then you'd need "#define old_inline __inline; #undef __inline; #define __inline static old_inline" or somesuch atrocity.)

IMO, if you've got any kind of support at all for this library, I'd send them a "WTF?" email. :)

[cjsmith.livejournal.com]

Ohhhhh yes: static __inline would be great. It's what I had hoped to see when I looked in that .h file (that, or macros).

I'm using gcc, yep. Got it in one. :-)

[brooksmoses]

Hah -- I was right about this being related to the GCC/inline weirdness, I think. See this post for a review of the issues.

In C99, "inline" means, roughly, the same thing as "static inline". However, GCC still defaults to using the pre-C99 meaning, where it's only a compiler hint with no actual semantic meaning (and so externally-visible symbols should still get emitted).

Passing the -std=gnu99 option to GCC, if you're using a sufficiently recent version, should do the trick (though it may cause other problems).

(I will note that this is all predicated on GCC treating "inline" and "__inline" as identical, which I think is the case, but I'm not absolutely certain of it.)

[cjsmith.livejournal.com]

Cool! Thanks for the link.

It would be spectacularly awful if "-std=gnu99" were incompatible with this system. I wouldn't put it past 'em. But I haven't tried it yet. Other things ate my afternoon. :)