Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.lang.c
Subject: __STDC__ defined as zero a problem
Message-ID: <225800190@uxe.cso.uiuc.edu>
Date: 23 Jun 89 19:32:00 GMT
Lines: 41
Nf-ID: #N:uxe.cso.uiuc.edu:225800190:000:1225
Nf-From: uxe.cso.uiuc.edu!mcdonald    Jun 23 14:32:00 1989


I have noticed several programs posted to the net, or available
by ftp somewhere that contain lines like

#if __STDC__
  /* usually function prototypes */
#else
  /* old style declarations */
#endif

I find this a bit objectionable, in that this prevents getting the
benefits of new-style declarations using compilers that support them
but, correctly, declare __STDC__ to be zero or don't declare it at all.

It would be nice if they looked something like

#ifdef ANSI_prototypes
#undef ANSI_prototypes
#define ANSI_prototypes 1
#else
#define ANSI_prototypes 0
#endif

#if ((__STDC__) | (ANSI_prototypes))
  /* the rest as above....

Where ANSI_prototypes could be defined on the command line.

I admit that sort of stuff could lead to command-line pollution
by things like defining ANSI_trigraphs, ANSI_this, ANSI_that, etc.

On the other hand, though __STDC__ is supposed to be defined as 1 
for comforming compilers , and not redefinable, (is this correct,
standards gurus?) it might be possible in a not-really ANSI-C
compiler to make __STDC__ be defined as 0, and redefinable. The
standard surely shouldn't object to this, should it?

Your comments and flames are welcome.

Doug McDonald (mcdonald@uxe.cso.uiuc.edu)