This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

STDC_0_IN_SYSTEM_HEADERS on Solaris... Painful


Hi everyone,

I just wanted to share some confustion, which was ultimately related to
STDC_0_IN_SYSTEM_HEADERS - maybe it was deserved, maybe it's sun fault - but
I think there's a lesson about things behaving in an obvious way in there
somewhere.

Today I tried to compile KDE.  Somehow or other, I have /usr/include/X11 on
my system, which is just a link to /usr/openwin/include/X11.  I beleive this
to be standard on Solaris 7, as I've not made the links myself.  Anyhow,
after a bit of mucking around, almost everything compiled with minor changes
- except kdm.  I looked at it a while - seems like __STDC__ isn't getting
set to 1, although the X include files expect it to be.  Quick test program
(test1) shows me in fact it is getting set to 1.  Include the one X include
file that does a test of __STDC__ being one and change my check to check for
the result- test shows it isn't getting set (result is "__STDC__ is not
defined")- so __STDC__ is not 1 when the header file is parsed...

Imagine my surprise then, when I pasted the contents of Xfuncproto.h into
the second test program (test3.c), commented out the include, and it worked
(result is "__STDC__ is defined as: 1").  Imagine my further surprise when
compiling test2.c with -I/usr/openwin/include, and getting the correct
result...

Of course after a bit of digging, I found the problem is with gcc's cpp.  At
first I thought I may have a broken installation (I just downloaded it from
sunfreeware), so I built it from scratch.  Same problem.  So I dug around
some, and eventually found STDC_0_IN_SYSTEM_HEADERS (after debugging cpp).
So I read the mailing list - understand why it's there, but still - it seems
non-intuitive and in my case, slightly painful.

I've thought of potential workarounds - handle /usr/include/X11 specially
inside of cpp - that seems wrong; change the #if __STDC__ to #if
defined(__STDC__) in these files (which is what I ultimately did) - or
always remembering to configure with the X files in /usr/openwin/include -
which might be the right approach, but seemed a little painful.

As an aside I removed /usr/include/X11 for a little while, and rather than
reconfiguring, compiled with C_INCLUDE_PATH set to /usr/openwin/include -
and got the broken result - is that the intended behaviour - now for
*anything* set in that path to be thought of as a system header???  This
seems really counterintuitive...

Anyhow, I hope someone appreciates this as anectdotal evidence for it being
a potentially bad idea to have certain files preprocessed with one set of
things defined and others with others, without an obvious to find out what
is happening.

- Dave


For what it's worth, here are my tests...

test1.c:
int main() {
#ifdef __STDC__
	printf("__STDC__ is defined as: %d\n", __STDC__);
#else
	pritnf("__STDC__ is not defined\n");
#endif
}

test2.c
#include <X11/Xfuncproto.h>

int main() {
#ifdef NeedVarargsPrototypes
	printf("__STDC__ is defined as: %d\n", __STDC__);
#else
	pritnf("__STDC__ is not defined\n");
#endif
}

Xfuncproto.h says (without including any other headers):

#ifndef NeedVarargsPrototypes
#if __STDC__ || defined(__cplusplus) || defined(c_plusplus) || (FUNCPROTO&2)
#define NeedVarargsPrototypes 1
#else
#define NeedVarargsPrototypes 0
#endif
#endif /* NeedVarargsPrototypes */

test3.c:
#ifndef NeedVarargsPrototypes
#if __STDC__ || defined(__cplusplus) || defined(c_plusplus) || (FUNCPROTO&2)
#define NeedVarargsPrototypes 1
#else
#define NeedVarargsPrototypes 0
#endif
#endif /* NeedVarargsPrototypes */

int main() {
#ifdef NeedVarargsPrototypes
	printf("__STDC__ is defined as: %d\n", __STDC__);
#else
	pritnf("__STDC__ is not defined\n");
#endif
}




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]