Re: 1.5.8 build failure on Solaris 8
David Champion writes:
> The problem we're talking about is essentially a risk of using function
> pointers as elements of structures, not with the "open" symbol itself.
The risk is that of using function pointers as elements of structures,
but only when there's a possibility that the name you're using has been
defined as a macro.
> Changing the name of the symbol is just reducing the likelihood of
> namespace conflict,
Most libraries make trivial guarantees of the form "all macros have
all-caps names", making macro names very easy to avoid. Ironically,
it's only the standard libraries that screw the defenceless programmer
like this (and that only to grandfather in the option for the
traditional implementation of isalpha() et al and putchar() as macros).
It's true that changing the symbol name isn't a guarantee of fixing
this. (Nor is the (p->function)(args) notation if 'function' might be
defined as an object-like macro, but the standard doesn't permit that
for the function names it defines.)
But, in my experience, it makes the problem sufficiently unlikely that
it's a good approach.
> Thanks, Aaron, for the summary and for pointing out that workaround.
I should also clarify that it's not my workaround -- I've been aware of
it for years. I thought it was in the comp.lang.c FAQ list, but I can't
find it now.
--
Aaron Crane