Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > how this works ?

Reply
Thread Tools

how this works ?

 
 
Keith Thompson
Guest
Posts: n/a
 
      04-05-2008
lector <(E-Mail Removed)> writes:
> On Apr 5, 7:37 pm, Willem <(E-Mail Removed)> wrote:
>> Or you just return the new pointer:
>>
>> node *create_link_list(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).

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

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      04-26-2008
Keith Thompson wrote:

> lector <(E-Mail Removed)> writes:
>> On Apr 5, 7:37 pm, Willem <(E-Mail Removed)> wrote:
>>> Or you just return the new pointer:
>>>
>>> node *create_link_list(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.


 
Reply With Quote
 
 
 
 
Richard
Guest
Posts: n/a
 
      04-26-2008
santosh <(E-Mail Removed)> writes:

> Keith Thompson wrote:
>
>> lector <(E-Mail Removed)> writes:
>>> On Apr 5, 7:37 pm, Willem <(E-Mail Removed)> wrote:
>>>> Or you just return the new pointer:
>>>>
>>>> node *create_link_list(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.
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      04-26-2008
pete wrote:

> santosh wrote:
>> Keith Thompson wrote:
>>
>>> lector <(E-Mail Removed)> writes:
>>>> On Apr 5, 7:37 pm, Willem <(E-Mail Removed)> wrote:
>>>>> Or you just return the new pointer:
>>>>>
>>>>> node *create_link_list(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>

 
Reply With Quote
 
Default User
Guest
Posts: n/a
 
      04-26-2008
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
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      04-26-2008
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.

 
Reply With Quote
 
Default User
Guest
Posts: n/a
 
      04-26-2008
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
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      04-26-2008
In article <fuvmrh$ih2$(E-Mail Removed)>
santosh <(E-Mail Removed)> 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.


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 (4039.22'N, 11150.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      04-27-2008
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.

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      04-27-2008
Chris Torek wrote:

> In article <fuvmrh$ih2$(E-Mail Removed)>
> santosh <(E-Mail Removed)> 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.

>
> 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_atexit(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_by_atexit);
return(term_type = EXIT_FAILURE);
}

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
When I turn on my PC, it works, works, works. Problem! Fogar Computer Information 1 01-17-2006 12:57 AM
Read all of this to understand how it works. then check around on otherRead all of this to understand how it works. then check around on other thelisa martin Computer Support 2 08-18-2005 06:40 AM
[py2exe.i18n] English works, German works, but not French. What do I miss? F. GEIGER Python 3 08-06-2004 10:01 AM
After rebooting my PC works, works, works! Antivirus problem? Adriano Computer Information 1 12-15-2003 05:30 AM



Advertisments