how this works ?

D

Default User

santosh said:
As I see it, this is outside the scope of the standard.

Exactly. So the Standard doesn't care what they are specifically,
including whether they happen to be identical.
The "as-if" rule really only makes sense if it, in some way,
simplifies things for the implementation or makes things more
efficient.

Chapter and Verse? The as-if rule says that if you can't tell the
difference, there IS no difference.
Strictly speaking you may be right in your analysis, but I
still say that making EXIT_SUCCESS and EXIT_FAILURE the same is
something only a DS9k would do.

What's your point? We are discussing technical features. Whether there
happens to be any actual implementation that is structured that way is
besides the point.
Also this can break code registered with atexit which might execute
different code depending on what termination status was passed to
exit.

Example?





Brian
 
K

Keith Thompson

Chris Torek said:
There is another argument one can make, with clearer ground (less
appeal to philosophy). Consider the following C code fragment:

switch (f()) {
case EXIT_SUCCESS: ... code for success ... break;
case EXIT_FAILURE: ... code for failure ... break;
}

If EXIT_SUCCESS and EXIT_FAILURE are allowed, in some implementation,
to be "#define"d as the same value, this code will not compile
(because we are not allowed to have two "case"s with identical
constants). If they must be different, the code will compile.
The question then boils down to whether Standard C guarantees
that this code will compile, which *is* an observable effect.

Because I think that Standard C guarantees this code will compile,
I think that an implementation is not allowed to "#define" both as
the same constant, even on a host where the return value from main()
(or the value passed to exit() or _Exit()) is always discarded.

It seems to me your reasoning here is a bit circular.

I see no explicit guarantee in the standard that the above code is
valid, any more than this:

switch (f()) {
case EOF: ... break;
case EXIT_FAILURE: ... break;
}

is guaranteed to be valid.

Your code is valid if and only if EXIT_SUCCESS and EXIT_FAILURE have
distinct values, but in the absence of any such guarantee, I think a
compiler is free to reject it.

It certainly would make sense to guarantee that EXIT_SUCCESS and
EXIT_FAILURE are distinct, and it could be inconvenient if they
weren't.

Looking at what the standard actually says (C99 7.20p2):

The macros defined are
[...]
EXIT_FAILURE
and
EXIT_SUCCESS
which expand to integer constant expressions that can be used as
the argument to the exit function to return unsuccessful or
successful termination status, respectively, to the host
environment;
[...]

One could argue from this that they must be distinct in order to make
unsuccessful and successful termination statuses distinguishable (if
they're not, then this doesn't make sense) -- but it's an indirect
argument, and not a very strong one IMHO. And the same argument
implies that an implementation in which the host environment cannot
distinguish between successful and unsuccessful termination status is
non-conforming; I don't *think* that was the intent.

I wouldn't mind seeing a guarantee that EXIT_SUCCESS != EXIT_FAILURE,
and maybe even a guarantee that EXIT_SUCCESS == 0, along with an
allowance for the usefulness of the termination status to be
implementation-defined. On the other hand, if all existing hosted
implementations *are* able to distinguish between success and failure,
then perhaps the allowance isn't necessary.

But that's not quite what the standard actually says now.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top