Will EXIT_SUCCESS and EXIT_FAILURE have the same value on all platforms?

[William Payne]

Hello, I would like to know if EXIT_FAILURE/SUCCESS has the same value on
all platforms? I am writing a few scripts (I know shell scripts are
off-topic here) to test my C programs and they depend on looking at the
return values to know what to do. Since EXIT_FAILURE/SUCCESS are not
constants visible to the shell, I have to hard code their values in my shell
scripts. Say I move to another platform, but with the same shell, can I
still rely on my hard-coded values for EXIT_FAILURE/SUCCESS? If I cannot, I
guess I can work around it with a small helper program that informs the
shell of the values.

/ WP

 

[Jack Klein]

Hello, I would like to know if EXIT_FAILURE/SUCCESS has the same value on
all platforms? I am writing a few scripts (I know shell scripts are
off-topic here) to test my C programs and they depend on looking at the
return values to know what to do. Since EXIT_FAILURE/SUCCESS are not
constants visible to the shell, I have to hard code their values in my shell
scripts. Say I move to another platform, but with the same shell, can I
still rely on my hard-coded values for EXIT_FAILURE/SUCCESS? If I cannot, I
guess I can work around it with a small helper program that informs the
shell of the values.

/ WP

The C standard does not define any particular values for these macros
at all. EXIT_SUCCESS is often #defined to be 0, since it must have
exactly the same effect as a return value from main() or an argument
to the exit() function.

But I think you are barking up the wrong tree. In a shell script you
are interested in the value returned by the system to the invoker of a
program. That does not necessarily correspond directly to the values
returned by a C program to the system. In many cases common operating
systems limit the values to a much smaller range than that of all
possible ints.

You need to consult the documentation for your system to determine
what values it defines to represent success and failure. On many
systems there is one and only one value for success, and any other
value indicates a failure of one type or another.

 

[pete]

Hello, I would like to know if EXIT_FAILURE/SUCCESS
has the same value on all platforms?

There are no macros in the standard library
which have the same value on all platforms.

 

[Peter Nilsson]

There are no macros in the standard library
which have the same value on all platforms.

__STDC__ ?

NULL must be null pointer constant.

Those aside, C99 (hosted or freestanding) defines at least three library
macros of constant value in <stdbool.h>.

Of course, you could argue that you said 'platform' and not
'implementation', but then... what's a 'platform' in the context of standard
C?

 

[pete]

__STDC__ ?

NULL must be null pointer constant.

Those aside, C99 (hosted or freestanding)
defines at least three library macros of
constant value in <stdbool.h>.

Of course, you could argue that you said 'platform' and not
'implementation', but then...
what's a 'platform' in the context of standard C?

__STDC__ is 1 in C99, but all platforms/implementations aren't C99.

NULL can be defined as any null pointer constant,
0, 0L, (void*)0, ...

 

[Dan Pop]

__STDC__ is 1 in C99, but all platforms/implementations aren't C99.

What is the value of __STDC__ in C89?

NULL can be defined as any null pointer constant,
0, 0L, (void*)0, ...

But all of them have the same value, when used in a pointer context.

Dan

 

[Ben Pfaff]

There are no macros in the standard library
which have the same value on all platforms.

Trivially incorrect. Given the appropriate #include directives:
The macro "complex" always expands to "_Complex".
The macro "bool" always expands to "_Bool".
The macro "and" always expands to "&&".

 

[pete]

Dan Pop wrote:

What is the value of __STDC__ in C89?

The only reference to __STDC__ in my copy of the
C89 last public draft, is in a footnote about undefined behavior.

 

[Ben Pfaff]

The only reference to __STDC__ in my copy of the
C89 last public draft, is in a footnote about undefined behavior.

In the copy of _The Annotated ANSI C Standard_ I have here, 6.8.8
"Predefined Macro Names" says that __STDC__ should expand to 1.

 

[Keith Thompson]

The only reference to __STDC__ in my copy of the
C89 last public draft, is in a footnote about undefined behavior.

Interesting. I have two plain-text copies of (drafts of?) the ANSI
C89 standard:

http://members.optushome.com.au/sbiber/stuff/ansic89.txt.bz2
http://danpop.home.cern.ch/danpop/ansi.c

in both of them, section 3.8.8 (corresponding to section 6.8.8 of the
ISO C90 standard) is messed up. It looks like the plain-text versions
were generated from some other format, and the conversion was confused
by some (but not all) instances of __FOO__.

The ISO C90 standard, section 6.8.8, says:

__STDC__ The decimal constant 1, intended to indicate a conforming
implementation.

I presume a correct copy of the C89 standard would say the same thing.

 

[CBFalconer]

The only reference to __STDC__ in my copy of the C89 last public
draft, is in a footnote about undefined behavior.

Your search mechanism isn't very good. Get the text version:

6.10.8 Predefined macro names

[#1] The following macro names shall be defined by the
implementation:

... snip quote ...

__STDC__ The decimal constant 1, intended to indicate a
conforming implementation.

 

[pete]

Interesting. I have two plain-text copies of (drafts of?) the ANSI
C89 standard:

http://members.optushome.com.au/sbiber/stuff/ansic89.txt.bz2
http://danpop.home.cern.ch/danpop/ansi.c

in both of them, section 3.8.8 (corresponding to section 6.8.8 of the
ISO C90 standard) is messed up. It looks like the plain-text versions
were generated from some other format, and the conversion was confused
by some (but not all) instances of __FOO__.

The ISO C90 standard, section 6.8.8, says:

__STDC__ The decimal constant 1,
intended to indicate a conforming implementation.

I presume a correct copy of the C89 standard would say the same thing.

Thank you.

 

[Dan Pop]

The only reference to __STDC__ in my copy of the
C89 last public draft, is in a footnote about undefined behavior.

This is because I've never bothered to fix that part of the plain
text version of the draft, which was badly damaged in the document I've
used as input:

3.8.8 Predefined macro names

The following macro names shall be defined by the implementation:
The line number of the current source line (a decimal constant). The
presumed name of the source file (a character string literal). The
date of translation of the source file (a character string literal of
the form Mmm dd yyyy , where the names of the months are the same as
those generated by the asctime function, and the first character of dd
is a space character if the value is less than 10). If the date of
translation is not available, an implementation-defined valid date
shall be supplied. The time of translation of the source file (a
character string literal of the form hh:mm:ss as in the time generated
by the asctime function). If the time of translation is not
available, an implementation-defined valid time shall be supplied.
the decimal constant 1.

Try to figure out what's missing from the last statement of the
paragraph ;-)

Grepping is not a valid substitute for reading that document...

Dan

 

[Dave Thompson]

Trivially incorrect. Given the appropriate #include directives:
The macro "complex" always expands to "_Complex".
The macro "bool" always expands to "_Bool".
The macro "and" always expands to "&&".

assert(anyarg) given <assert.h> with NDEBUG is ((void)0). Although why
this was so tightly specified is not clear to me; no program could
distinguish it from any other void expression, except by stringizing.

__LINE__ and possibly __FILE__ following a #line directive can be made
the same, and __LINE__ already is for an identical source file.

- David.Thompson1 at worldnet.att.net