Re: how this works ?

[santosh]

Keith Thompson wrote:

lector <hannibal.lecto r99@gmail.comwr ites:

>On Apr 5, 7:37 pm, Willem <wil...@stack.n lwrote:

>>Or you just return the new pointer:
>>>
>>node *create_link_li st(n)

>>
>One can do that but what if you can't malloc in create function
>because of some error ? For that, it might be necessary to return an
>int (EXIT_SUCCESS/EXIT_FAILURE) for checking.

>
I advise against using EXIT_SUCCESS and EXIT_FAILURE as status codes
for functions other than main. It's not absolutely guaranteed that
they have distinct values (though I've never heard of a system where
they don't).

You mean that there may be implementations where EXIT_SUCCESS ==
EXIT_FAILURE? If so how will the environment distinguish between the
two?

Many library functions return zero for success, non-zero for failure;
that's a reasonable convention to follow.

[Richard]

Re: how this works ?

santosh <santosh.k83@gm ail.comwrites:

Keith Thompson wrote:
>

>lector <hannibal.lecto r99@gmail.comwr ites:

>>On Apr 5, 7:37 pm, Willem <wil...@stack.n lwrote:
>>>Or you just return the new pointer:
>>>>
>>>node *create_link_li st(n)
>>>
>>One can do that but what if you can't malloc in create function
>>because of some error ? For that, it might be necessary to return an
>>int (EXIT_SUCCESS/EXIT_FAILURE) for checking.

>>
>I advise against using EXIT_SUCCESS and EXIT_FAILURE as status codes
>for functions other than main. It's not absolutely guaranteed that
>they have distinct values (though I've never heard of a system where
>they don't).

>
You mean that there may be implementations where EXIT_SUCCESS ==
EXIT_FAILURE? If so how will the environment distinguish between the
two?
>

>Many library functions return zero for success, non-zero for failure;
>that's a reasonable convention to follow.

There would be more chance of a chip bit accidentally toggling then
them not being the same IMO.

[pete]

Re: how this works ?

santosh wrote:

Keith Thompson wrote:
>

>lector <hannibal.lecto r99@gmail.comwr ites:

>>On Apr 5, 7:37 pm, Willem <wil...@stack.n lwrote:
>>>Or you just return the new pointer:
>>>>
>>>node *create_link_li st(n)
>>One can do that but what if you can't malloc in create function
>>because of some error ? For that, it might be necessary to return an
>>int (EXIT_SUCCESS/EXIT_FAILURE) for checking.

>I advise against using EXIT_SUCCESS and EXIT_FAILURE as status codes
>for functions other than main. It's not absolutely guaranteed that
>they have distinct values (though I've never heard of a system where
>they don't).

>
You mean that there may be implementations where EXIT_SUCCESS ==
EXIT_FAILURE? If so how will the environment distinguish between the
two?

There is no requirement for the system
to be able to distinguish between the two.

void main (void)

>Many library functions return zero for success, non-zero for failure;
>that's a reasonable convention to follow.

That's a good convention for when there may be
multiple modes of failure available.

For functions, like the ctype functions,
which return a value that is conceptually boolean,
returning one for success and zero for failure, makes more sense.

--
pete

[santosh]

Re: how this works ?

pete wrote:

santosh wrote:

>Keith Thompson wrote:
>>

>>lector <hannibal.lecto r99@gmail.comwr ites:
>>>On Apr 5, 7:37 pm, Willem <wil...@stack.n lwrote:
>>>>Or you just return the new pointer:
>>>>>
>>>>node *create_link_li st(n)
>>>One can do that but what if you can't malloc in create function
>>>because of some error ? For that, it might be necessary to return
>>>an int (EXIT_SUCCESS/EXIT_FAILURE) for checking.
>>I advise against using EXIT_SUCCESS and EXIT_FAILURE as status codes
>>for functions other than main. It's not absolutely guaranteed that
>>they have distinct values (though I've never heard of a system where
>>they don't).

>>
>You mean that there may be implementations where EXIT_SUCCESS ==
>EXIT_FAILURE ? If so how will the environment distinguish between the
>two?

>
There is no requirement for the system
to be able to distinguish between the two.
>
void main (void)

I don't get it. From n1256 section 7.20 para 3:

+-----
| 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;
+-----

The above seems to be indicate pretty clearly that EXIT_FAILURE and
EXIT_SUCCESS return different termination statuses to the host. How
could this happen if the implementation could not distinguish between
them?

<snip>

[Default User]

Re: how this works ?

santosh wrote:

The above seems to be indicate pretty clearly that EXIT_FAILURE and
EXIT_SUCCESS return different termination statuses to the host. How
could this happen if the implementation could not distinguish between
them?

What are you saying? If a host system doesn't have a way to distinguish
successful versus non-successful return, you can't have a C compiler?




Brian

[santosh]

Re: how this works ?

Default User wrote:

santosh wrote:
>
>

>The above seems to be indicate pretty clearly that EXIT_FAILURE and
>EXIT_SUCCESS return different termination statuses to the host. How
>could this happen if the implementation could not distinguish between
>them?

>
What are you saying? If a host system doesn't have a way to
distinguish successful versus non-successful return, you can't have a
C compiler?

As far as I can see EXIT_SUCCESS and EXIT_FAILURE merely return
successful termination status and unsuccessful termination status
respectively to the host environment. Whether the host is able to
distinguish between the two is not relevant to the C implementation.
What it can't do is to set EXIT_SUCCESS to be equal to EXIT_FAILURE.
They return different termination statuses and therefore must be
different.

That was what I was arguing in response to Keith Thompson's post
up-thread.

[Default User]

Re: how this works ?

santosh wrote:

Default User wrote:
>

santosh wrote:

The above seems to be indicate pretty clearly that EXIT_FAILURE and
EXIT_SUCCESS return different termination statuses to the host. How
could this happen if the implementation could not distinguish

between >them?

What are you saying? If a host system doesn't have a way to
distinguish successful versus non-successful return, you can't have
a C compiler?

>
As far as I can see EXIT_SUCCESS and EXIT_FAILURE merely return
successful termination status and unsuccessful termination status
respectively to the host environment.

Which have to be values meaningful to the host.

Whether the host is able to
distinguish between the two is not relevant to the C implementation.
What it can't do is to set EXIT_SUCCESS to be equal to EXIT_FAILURE.
They return different termination statuses and therefore must be
different.

I'm not sure the Standard says they must be different. If the Standard
doesn't specify that they are required to be non-equal, and the host
system can't distinguish, then the as-if rule would seem to say that
they could be the same for some implementation.




Brian

[Chris Torek]

Re: how this works ?

In article <fuvmrh$ih2$1@r egistered.motza rella.org>
santosh <santosh.k83@gm ail.comwrote:

>As far as I can see EXIT_SUCCESS and EXIT_FAILURE merely return
>successful termination status and unsuccessful termination status
>respectively to the host environment.

Right.

>Whether the host is able to distinguish between the two is not
>relevant to the C implementation.

Maybe. (I think this is correct, but I think one can at least
argue that it is not. This gets to be one of those philosophical
questions, like "if a tree falls in the forest and there is no one
around to observe it, does it make `a noise'", where the answer
hinges on the exact defintion of `noise'. If noise means "any
sound", then -- assuming we understand physics correctly -- it does
make sound and hence noise, but if it means "a sound that annoys
a person", then since there is no person being annoyed, it makes
no `noise'.)

>What it can't do is to set EXIT_SUCCESS to be equal to EXIT_FAILURE.
>They return different termination statuses and therefore must be
>different.

But then we can appeal to the "as-if" rule and claim that, if the
user cannot tell whether they returned different statuses, the
compiler is allowed to have them return the same status, or even
no status at all. In which case, perhaps the compiler's freedom
to alter or remove the value returned from main() extends to further
freedom to "#define" both with the same value. In other words, if
the effect is not observable, the compiler can do whatever it likes:
we will not even be able to tell whether it has done anything.

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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html

[santosh]

Re: how this works ?

Default User wrote:

santosh wrote:

>Default User wrote:

santosh wrote:
>
>The above seems to be indicate pretty clearly that EXIT_FAILURE
>and EXIT_SUCCESS return different termination statuses to the
>host. How could this happen if the implementation could not
>distinguish between them?
>
What are you saying? If a host system doesn't have a way to
distinguish successful versus non-successful return, you can't have
a C compiler?

>>
>As far as I can see EXIT_SUCCESS and EXIT_FAILURE merely return
>successful termination status and unsuccessful termination status
>respectively to the host environment.

>
Which have to be values meaningful to the host.

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

>Whether the host is able to
>distinguish between the two is not relevant to the C implementation.
>What it can't do is to set EXIT_SUCCESS to be equal to EXIT_FAILURE.
>They return different termination statuses and therefore must be
>different.

>
I'm not sure the Standard says they must be different. If the Standard
doesn't specify that they are required to be non-equal, and the host
system can't distinguish, then the as-if rule would seem to say that
they could be the same for some implementation.

The "as-if" rule really only makes sense if it, in some way, simplifies
things for the implementation or makes things more efficient. 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.

Also this can break code registered with atexit which might execute
different code depending on what termination status was passed to exit.
Again this might happen only in theory, but it's nevertheless another
point in favour of keeping EXIT_SUCCESS and EXIT_FAILURE distinct from
each other.

[santosh]

Re: how this works ?

Chris Torek wrote:

In article <fuvmrh$ih2$1@r egistered.motza rella.org>
santosh <santosh.k83@gm ail.comwrote:

>>As far as I can see EXIT_SUCCESS and EXIT_FAILURE merely return
>>successful termination status and unsuccessful termination status
>>respectivel y to the host environment.

>
Right.
>

>>Whether the host is able to distinguish between the two is not
>>relevant to the C implementation.

>
Maybe. (I think this is correct, but I think one can at least
argue that it is not. This gets to be one of those philosophical
questions, like "if a tree falls in the forest and there is no one
around to observe it, does it make `a noise'", where the answer
hinges on the exact defintion of `noise'. If noise means "any
sound", then -- assuming we understand physics correctly -- it does
make sound and hence noise, but if it means "a sound that annoys
a person", then since there is no person being annoyed, it makes
no `noise'.)
>

>>What it can't do is to set EXIT_SUCCESS to be equal to EXIT_FAILURE.
>>They return different termination statuses and therefore must be
>>different.

>
But then we can appeal to the "as-if" rule and claim that, if the
user cannot tell whether they returned different statuses, the
compiler is allowed to have them return the same status, or even
no status at all. In which case, perhaps the compiler's freedom
to alter or remove the value returned from main() extends to further
freedom to "#define" both with the same value. In other words, if
the effect is not observable, the compiler can do whatever it likes:
we will not even be able to tell whether it has done anything.
>
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.

An even stronger case (IMHO) for making EXIT_FAILURE and EXIT_SUCCESS
different might be the following code:

#include <stdlib.h>

int term_type;

void called_by_atexi t(void) {
if (term_type == EXIT_SUCCESS) {
/* some code */
}
else if (term_type == EXIT_FAILURE) {
/* some other code */
}
else {
/* yet some other code */
}
return;
}

int main(void) {
atexit(called_b y_atexit);
return(term_typ e = EXIT_FAILURE);
}

In called_by_atexi t() the wrong block of code will be executed.

[Default User]

Re: how this works ?

santosh wrote:

Default User wrote:

santosh wrote:

As far as I can see EXIT_SUCCESS and EXIT_FAILURE merely return
successful termination status and unsuccessful termination status
respectively to the host environment.

Which have to be values meaningful to the host.

>
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.

I'm not sure the Standard says they must be different. If the
Standard doesn't specify that they are required to be non-equal,
and the host system can't distinguish, then the as-if rule would
seem to say that they could be the same for some implementation.

>
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