Preprocessor Directives

[Water Cooler v2]

Sorry if this is a foolish question, but here it is.

I see things like

#ifndef STDC

...blah
#endif

#ifdef WIN32
...blah
#endif

in open source projects but I do not see where they actually define
these symbols WIN32 and STDC. I know what the #ifdef and #ifndef
preprocessor directives mean. I want to know how these symbols like
STDC and WIN32 are chosen. Are they some pre-defined symbols that
individual compilers expect? Or are they included when building the
project? What gives?

[Eric Sosman]

Water Cooler v2 wrote:

Sorry if this is a foolish question, but here it is.

I see things like

#ifndef STDC

...blah
#endif

#ifdef WIN32
...blah
#endif

in open source projects but I do not see where they actually define
these symbols WIN32 and STDC. I know what the #ifdef and #ifndef
preprocessor directives mean. I want to know how these symbols like
STDC and WIN32 are chosen. Are they some pre-defined symbols that
individual compilers expect? Or are they included when building the
project? What gives?

A few preprocessor symbols like __STDC__ (not STDC) are
defined by all Standard-conforming C compilers. Others may
be defined by particular compilers, but the only place to
learn about them is from the compilers' documentation. Many
compilers allow preprocessor symbols to be defined at the time
the compiler is invoked (often by means of command-line options);
you'll need to check the build scripts or Makefiles or whatever
other machinery the project uses.

As it happens, a compiler that predefines WIN32 (without
being provoked by a command-line option or something) is not
Standard-conforming. The identifier WIN32 should be available
for any use the programmer cares to make of it. The following
is a strictly conforming program, and a compiler whose predefined
names clash with anything here is non-conforming:

#include <stdio.h>
#include <stdlib.h>
#define SPARC EXIT_SUCCESS
#define I386 EXIT_FAILURE
int main(int WIN32, char **STDC) {
char UNIX[] = "Hello, world!";
int VAX = puts(UNIX);
return VAX == EOF ? SPARC : I386;
}

--
Eric Sosman
es*****@acm-dot-org.invalid

[Malcolm]

"Water Cooler v2" <wt*****@yahoo.com> wrote

#ifndef STDC

...blah
#endif

#ifdef WIN32
...blah
#endif

in open source projects but I do not see where they actually define
these symbols WIN32 and STDC. I know what the #ifdef and #ifndef
preprocessor directives mean. I want to know how these symbols like
STDC and WIN32 are chosen. Are they some pre-defined symbols that
individual compilers expect? Or are they included when building the
project? What gives?

Compilers are allowed to define symbols to the preprocessor before they
start compilation. Usually there is also an option to define your own
symbols.

WIN32, for instance, looks like a symbol that is defined on 32-bit MS
Windows systems. A program might want to take advantage of this, for
instnace to replace a generic function with a faster windows-specific call.

[Lawrence Kirby]

On Mon, 04 Jul 2005 15:52:19 -0400, Eric Sosman wrote:

....

As it happens, a compiler that predefines WIN32 (without
being provoked by a command-line option or something) is not
Standard-conforming.
It creates a non-conforming implementation whether WIN32 is built in or
specified in the command line. The conformance of a compiler is highly
dependent on the command line options given to it, including macro
predefinitions.
The identifier WIN32 should be available
for any use the programmer cares to make of it. The following
is a strictly conforming program, and a compiler whose predefined
names clash with anything here is non-conforming:

#include <stdio.h>
#include <stdlib.h>
#define SPARC EXIT_SUCCESS
#define I386 EXIT_FAILURE
int main(int WIN32, char **STDC) {
char UNIX[] = "Hello, world!";
int VAX = puts(UNIX);
return VAX == EOF ? SPARC : I386;
}

Right, if any command line options break that code they have broken the
conformance of the implementation.

The program does curiously return EXIT_SUCCESS when puts() fails.

Lawrence

[CBFalconer]

Lawrence Kirby wrote:

On Mon, 04 Jul 2005 15:52:19 -0400, Eric Sosman wrote:
.... snip ...

The identifier WIN32 should be available
for any use the programmer cares to make of it. The following
is a strictly conforming program, and a compiler whose predefined
names clash with anything here is non-conforming:

#include <stdio.h>
#include <stdlib.h>
#define SPARC EXIT_SUCCESS
#define I386 EXIT_FAILURE
int main(int WIN32, char **STDC) {
char UNIX[] = "Hello, world!";
int VAX = puts(UNIX);
return VAX == EOF ? SPARC : I386;
}

Right, if any command line options break that code they have broken
the conformance of the implementation.

The program does curiously return EXIT_SUCCESS when puts() fails.

Precisely as it has been told to. It normally returns
EXIT_FAILURE. However, how do you make puts fail here for testing
purposes?

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Lawrence Kirby]

On Tue, 05 Jul 2005 15:25:43 +0000, CBFalconer wrote:

Lawrence Kirby wrote:

On Mon, 04 Jul 2005 15:52:19 -0400, Eric Sosman wrote:
... snip ...

The identifier WIN32 should be available
for any use the programmer cares to make of it. The following
is a strictly conforming program, and a compiler whose predefined
names clash with anything here is non-conforming:

#include <stdio.h>
#include <stdlib.h>
#define SPARC EXIT_SUCCESS
#define I386 EXIT_FAILURE
int main(int WIN32, char **STDC) {
char UNIX[] = "Hello, world!";
int VAX = puts(UNIX);
return VAX == EOF ? SPARC : I386;
}

Right, if any command line options break that code they have broken
the conformance of the implementation.

The program does curiously return EXIT_SUCCESS when puts() fails.

Precisely as it has been told to.

That is what the source specifies, yes. It is unusual behaviour for
e Hello world program however.
It normally returns EXIT_FAILURE.
Well, I said it is curious not that it is wrong.
However, how do you make puts fail here for testing
purposes?

You need control of the environment in some way e.g. how the program is
invoked so it will be platform specific. stdout needs to be attached to an
interactive device to ensure that it is not fully buffered but that device
must fail the write. Under Unix you could maybe do this using a pseudo-tty.

Lawrence