[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Tru64 C V6 and _AC_PROG_CC_STDC

From: Norman Gray
Subject: Tru64 C V6 and _AC_PROG_CC_STDC
Date: Tue, 18 Jan 2005 18:17:06 +0000


OSF/Tru64 C version 6 thwarts _AC_PROG_CC_STDC: that macro should add -std1 to the CFLAGS when this compiler is being used, but it doesn't.

The reason is that Tru64 cc has an almost-ANSI flag -std, which is the default (the default used to be -std0, meaning K&R C). This passes the test in _AC_PROG_CC_STDC, with the result that nothing is added to CFLAGS. However this mode defines __STDC__ to 0. This confuses code which tests this macro with #if rather than #ifdef, with the result that the compiler is invited to compile K&R-style code, causing it to fail. The -std1 option defines __STDC__ to 1, as nature intended.

Of course, defining __STDC__ to zero isn't terribly helpful, since this has no meaning defined by the standard. However it seems to be intended (on Tru64 at least) to indicate that all of ISO standard C is supported, but not strictly enforced. See man page excerpts below. Solaris cc has similar behaviour, defining __STDC__ to be 1 with option -Xa (full conformance), zero with -Xt (`transition'), and undefined with -Xs (K&R C).

The correct behaviour would, I believe, be obtained by inserting

#if !__STDC__
  choke me

anywhere in _AC_PROG_CC_STDC. Can I suggest that this goes into the macro?

There was some discussion of this in January 2004, starting at <http://lists.gnu.org/archive/html/autoconf/2004-01/msg00111.html>. The conclusion there was that _AC_PROG_CC_STDC should determine whether it has to include -std, not -std1, because `-std1 disables some useful extensions on Tru64'.

I believe this is wrong behaviour: If I'm (implicitly) invoking this macro, I'm looking for a compiler option that gives me standard C. Having __STDC__ equal to 0 violates the standard, thus this test is giving the wrong result. I've no idea what these `useful extensions' are, and if I did, I'd certainly be sure to avoid them, and I would like to rely on my compiler telling me I'm accidentally using them.

There was also some discussion of Tru64 C and this macro in June 2003 <http://lists.gnu.org/archive/html/autoconf-patches/2003-06/ msg00009.html>

There's a current problem: if you process the configure from GNU m4 1.4 with autoconf 2.57, and run the resulting ./configure, the resulting Makefile does not have -std1 in the CFLAGS, so has ___STDC__ zero, with the result that m4 fails to build on Tru64. This is slightly artificial, of course, but not unrealistic. It can probably be fixed for m4 (though I haven't tried it yet) by replacing a couple of #if __STDC__ with #ifdef __STDC__, but this is a workaround, and doesn't affect the fact that the macro is producing the wrong answer.

All the best,


From the man page for 'Compaq C V6.4-014 on Compaq Tru64 UNIX':

Selects the relaxed ANSI language mode. This is the default. Enforces
      the ANSI C standard, but allows some common programming practices
      disallowed by the standard.
      This option sets the macro __STDC__ to 0.

Selects the K & R language mode.[...] The -std0 option leaves the __STDC__
      macro undefined.

Selects the strict ANSI language mode. Strictly enforces the ANSI C standard and all its prohibitions (such as those that apply to the han- dling of void types, the definition of lvalues in expressions, the mix-
      ing of integrals and pointers, and the modification of rvalues).
      This option sets the macro __STDC__ to 1.

Norman Gray  :  Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/  :  www.starlink.ac.uk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]