Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #90116 > unrolled thread

EXIT_SUCCESS

Back to article view | Back to comp.lang.c

Contents

  EXIT_SUCCESS Real Troll <real.troll@trolls.com> - 2016-07-08 00:00 -0300
    Re: EXIT_SUCCESS luser droog <luser.droog@gmail.com> - 2016-07-07 19:54 -0700
    Re: EXIT_SUCCESS Ian Collins <ian-news@hotmail.com> - 2016-07-08 15:03 +1200
    Re: EXIT_SUCCESS James Kuyper <jameskuyper@verizon.net> - 2016-07-07 23:20 -0400
      Re: EXIT_SUCCESS Richard Heathfield <rjh@cpax.org.uk> - 2016-07-08 10:19 +0100
        Re: EXIT_SUCCESS Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-08 03:25 -0700
          Re: EXIT_SUCCESS Richard Heathfield <rjh@cpax.org.uk> - 2016-07-08 13:49 +0100
          Re: EXIT_SUCCESS Keith Thompson <kst-u@mib.org> - 2016-07-08 08:33 -0700
            Re: EXIT_SUCCESS Gareth Owen <gwowen@gmail.com> - 2016-07-08 18:03 +0100
              Re: EXIT_SUCCESS Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-08 19:11 +0100
                Re: EXIT_SUCCESS "Osmium" <r124c4u102@comcast.net> - 2016-07-08 14:25 -0500
                  Re: EXIT_SUCCESS Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-08 20:34 +0100
                    Re: EXIT_SUCCESS Ken Brody <kenbrody@spamcop.net> - 2016-07-11 19:10 -0400
                  Re: EXIT_SUCCESS Robert Wessel <robertwessel2@yahoo.com> - 2016-07-10 01:21 -0500
                  Re: EXIT_SUCCESS Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-10 16:09 -0600
                  Re: EXIT_SUCCESS Keith Thompson <kst-u@mib.org> - 2016-07-10 16:01 -0700
                    Re: EXIT_SUCCESS "Osmium" <r124c4u102@comcast.net> - 2016-07-10 18:30 -0500
                      Re: EXIT_SUCCESS Keith Thompson <kst-u@mib.org> - 2016-07-10 17:00 -0700
                      Re: EXIT_SUCCESS James Kuyper <jameskuyper@verizon.net> - 2016-07-10 22:43 -0400
                        Re: EXIT_SUCCESS Siri Cruise <chine.bleu@yahoo.com> - 2016-07-10 22:31 -0700
                          Re: EXIT_SUCCESS raltbos@xs4all.nl (Richard Bos) - 2016-07-11 08:24 +0000
                          Re: EXIT_SUCCESS Ken Brody <kenbrody@spamcop.net> - 2016-07-11 19:18 -0400
                    Re: EXIT_SUCCESS gazelle@shell.xmission.com (Kenny McCormack) - 2016-07-11 00:47 +0000
                  Re: EXIT_SUCCESS gordonb.0aikd@burditt.org (Gordon Burditt) - 2016-07-12 18:52 -0500
                    Re: EXIT_SUCCESS "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-12 20:32 -0400
                      Re: EXIT_SUCCESS Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-12 20:59 -0600
                      Re: EXIT_SUCCESS gordonb.a2m2l@burditt.org (Gordon Burditt) - 2016-07-13 02:11 -0500
                        Re: EXIT_SUCCESS James Kuyper <jameskuyper@verizon.net> - 2016-07-13 11:26 -0400
                          Re: EXIT_SUCCESS Keith Thompson <kst-u@mib.org> - 2016-07-13 08:48 -0700
                      Re: EXIT_SUCCESS Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-18 09:54 -0700
              Re: EXIT_SUCCESS James Kuyper <jameskuyper@verizon.net> - 2016-07-08 17:46 -0400
                Re: EXIT_SUCCESS Keith Thompson <kst-u@mib.org> - 2016-07-09 13:13 -0700
                  Re: EXIT_SUCCESS jgh@mdfs.net - 2016-07-25 04:42 -0700
                    Re: EXIT_SUCCESS Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 13:07 +0100
                      Re: EXIT_SUCCESS Udyant Wig <udyant.wig@gmail.com> - 2016-07-25 20:05 +0530
                      Re: EXIT_SUCCESS raltbos@xs4all.nl (Richard Bos) - 2016-07-25 16:06 +0000
                        Re: EXIT_SUCCESS Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 17:41 +0100
                          Re: EXIT_SUCCESS Keith Thompson <kst-u@mib.org> - 2016-07-25 11:04 -0700
                            Re: EXIT_SUCCESS Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 19:14 +0100
                              Re: EXIT_SUCCESS BartC <bc@freeuk.com> - 2016-07-25 22:00 +0100
                                Re: EXIT_SUCCESS Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 22:03 +0100
                                  Re: EXIT_SUCCESS BartC <bc@freeuk.com> - 2016-07-25 22:41 +0100
                                    Re: EXIT_SUCCESS jadill33@gmail.com - 2016-07-25 14:50 -0700
                                Re: EXIT_SUCCESS Keith Thompson <kst-u@mib.org> - 2016-07-25 15:04 -0700
                            Re: EXIT_SUCCESS David Brown <david.brown@hesbynett.no> - 2016-07-26 10:43 +0200
                          Re: EXIT_SUCCESS jadill33@gmail.com - 2016-07-25 14:41 -0700
                            Re: EXIT_SUCCESS David Brown <david.brown@hesbynett.no> - 2016-07-26 10:59 +0200
                              Re: EXIT_SUCCESS jadill33@gmail.com - 2016-07-27 06:20 -0700
                                Re: EXIT_SUCCESS Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-27 15:44 +0100
                                  Re: EXIT_SUCCESS Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-27 16:22 +0100
                                  Re: EXIT_SUCCESS Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-27 11:20 -0600
                                  Re: EXIT_SUCCESS luser droog <luser.droog@gmail.com> - 2016-07-27 15:32 -0700
                                    Re: EXIT_SUCCESS Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-28 14:47 +0100
                    Re: EXIT_SUCCESS Keith Thompson <kst-u@mib.org> - 2016-07-25 08:46 -0700
                      Re: EXIT_SUCCESS David Brown <david.brown@hesbynett.no> - 2016-07-26 12:44 +0200
                        Re: EXIT_SUCCESS Keith Thompson <kst-u@mib.org> - 2016-07-26 08:24 -0700
                          Re: EXIT_SUCCESS David Brown <david.brown@hesbynett.no> - 2016-07-26 19:26 +0200
                        Re: EXIT_SUCCESS BartC <bc@freeuk.com> - 2016-07-26 18:03 +0100
                Re: EXIT_SUCCESS Ken Brody <kenbrody@spamcop.net> - 2016-07-11 19:15 -0400
                  Re: EXIT_SUCCESS supercat@casperkitty.com - 2016-07-11 16:46 -0700
                  Re: EXIT_SUCCESS raltbos@xs4all.nl (Richard Bos) - 2016-07-15 13:51 +0000
                    Re: EXIT_SUCCESS supercat@casperkitty.com - 2016-07-15 08:07 -0700
                    Re: EXIT_SUCCESS Ken Brody <kenbrody@spamcop.net> - 2016-07-15 14:33 -0400
                      Re: EXIT_SUCCESS raltbos@xs4all.nl (Richard Bos) - 2016-07-23 09:07 +0000
                        Re: EXIT_SUCCESS Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-23 16:44 -0500
                          Re: EXIT_SUCCESS Ken Brody <kenbrody@spamcop.net> - 2016-07-25 10:36 -0400
                            Re: EXIT_SUCCESS Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-25 15:28 -0500
                Re: EXIT_SUCCESS Rosario19 <Ros@invalid.invalid> - 2016-07-18 09:45 +0200
          Re: EXIT_SUCCESS gordonb.bitq1@burditt.org (Gordon Burditt) - 2016-07-08 17:56 -0500
    Re: EXIT_SUCCESS Keith Thompson <kst-u@mib.org> - 2016-07-08 08:35 -0700
      Re: EXIT_SUCCESS luser droog <luser.droog@gmail.com> - 2016-07-31 15:03 -0700
        Re: EXIT_SUCCESS Real Troll <real.troll@trolls.com> - 2016-07-31 18:09 -0400
        Re: EXIT_SUCCESS luser droog <luser.droog@gmail.com> - 2016-07-31 15:36 -0700
        Re: EXIT_SUCCESS James Kuyper <jameskuyper@verizon.net> - 2016-08-01 10:09 -0400

Page 1 of 4  [1] 2 3 4  Next page →

#90116 — EXIT_SUCCESS

In C instead of using return 0; we can write EXIT_SUCCESS; so the 
question is:

Is it

EXIT_SUCCESS;

or

EXIT_SUCCESS();

[toc] | [next] | [standalone]

#90117

On Thursday, July 7, 2016 at 9:41:36 PM UTC-5, Real Troll wrote:
> In C instead of using return 0; we can write EXIT_SUCCESS; so the 
> question is:
> 
> Is it
> 
> EXIT_SUCCESS;
> 
> or
> 
> EXIT_SUCCESS();

Ask the compiler! (By writing a small program
and attempting to compile it.)

[toc] | [prev] | [next] | [standalone]

#90118

On 07/ 8/16 03:00 PM, Real Troll wrote:
> In C instead of using return 0; we can write EXIT_SUCCESS; so the
> question is:
>
> Is it
>
> EXIT_SUCCESS;
>
> or
>
> EXIT_SUCCESS();

No.

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#90119

On 07/07/2016 11:00 PM, Real Troll wrote:
> In C instead of using return 0; we can write EXIT_SUCCESS; ...

Incorrect.

> ... so the 
> question is:
> 
> Is it
> 
> EXIT_SUCCESS;
> 
> or
> 
> EXIT_SUCCESS();

Neither.

> If the return type of the main function is a type compatible with
> int, a return from the initial call to the main function is
> equivalent to calling the exit function with the value returned by
> the main function as its argument; ...
5.1.2.2.3p1

Note, in particular, that this does not apply to a return statement in
any other context. In particular, it does not apply return statements
executed from within main() when it is called by your own code (which is
permitted, though not very common).

One way to think about this is to think of the initial call to main() as
occurring in the equivalent of the following context (though in reality
it's likely to be assembly language rather than C code):

    // parse the command line, constructing argv[]
    // put the number of entries in argv[] in argc
    exit(main(argc, argv));


<stdlib.> contains #definitions for the following macros:
>         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;
(7.22p3)

When calling exit(status),
> ... If the value of status is zero or EXIT_SUCCESS, an
> implementation-defined form of the status successful
> termination is returned. If the value of status is EXIT_FAILURE, an
> implementation-defined form of the status unsuccessful termination is
> returned. Otherwise the status returned is implementation-defined.
(7.22.4.4p5)

To summarize:

exit(0) and exit(EXIT_SUCCESS) are two different ways provided by the C
standard for exiting your program with a successful termination status.
exit(EXIT_FAILURE) is the only way defined by the C standard for exiting
your program with an unsuccessful termination status.

    return 0;
    return EXIT_SUCCESS;
    return EXIT_FAILUER;

have the same effect if (but only if) they are executed inside the
initial call to main().

[toc] | [prev] | [next] | [standalone]

#90123

On 08/07/16 04:20, James Kuyper wrote:
<snip>
>      return EXIT_FAILUER;

s/ER/RE/

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#90125

On Friday, July 8, 2016 at 10:19:24 AM UTC+1, Richard Heathfield wrote:
> On 08/07/16 04:20, James Kuyper wrote:
> <snip>
> >      return EXIT_FAILUER;
> 
> s/ER/RE/
> 
In structured programming you can never have the line

return EXIT_FAILURE;

You can write "return EXIT_SUCCESS" if the program has no failure modes it
can detect, but not "return EXIT_FAILURE";

[toc] | [prev] | [next] | [standalone]

#90128

On 08/07/16 11:25, Malcolm McLean wrote:
> On Friday, July 8, 2016 at 10:19:24 AM UTC+1, Richard Heathfield wrote:
>> On 08/07/16 04:20, James Kuyper wrote:
>> <snip>
>>>       return EXIT_FAILUER;
>>
>> s/ER/RE/
>>
> In structured programming

Malcolm, this thread wasn't about structured programming. If you want to 
talk about C's mechanisms for programming termination in a structured 
programming context, that's fine - just start a new thread. It might 
even be interesting.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#90129

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, July 8, 2016 at 10:19:24 AM UTC+1, Richard Heathfield wrote:
>> On 08/07/16 04:20, James Kuyper wrote:
>> <snip>
>> >      return EXIT_FAILUER;
>> 
>> s/ER/RE/
>> 
> In structured programming you can never have the line
>
> return EXIT_FAILURE;
>
> You can write "return EXIT_SUCCESS" if the program has no failure modes it
> can detect, but not "return EXIT_FAILURE";

I would look forward to your explanation of how that makes any sense
at all (preferably, as Richard suggests, in a different thread)
if I thought there was a reasonable chance of that happening.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#90131

Keith Thompson <kst-u@mib.org> writes:

> I would look forward to your explanation of how that makes any sense
> at all (preferably, as Richard suggests, in a different thread)
> if I thought there was a reasonable chance of that happening.

Well if thought "structured" meant "SESE in all circumstances", and your 
program had at least one failure mode and one success mode you'd store 
your return value in a variable and return it in the sole return-statement.

[toc] | [prev] | [next] | [standalone]

#90133

Gareth Owen <gwowen@gmail.com> writes:

> Keith Thompson <kst-u@mib.org> writes:
>
>> I would look forward to your explanation of how that makes any sense
>> at all (preferably, as Richard suggests, in a different thread)
>> if I thought there was a reasonable chance of that happening.
>
> Well if thought "structured" meant "SESE in all circumstances", and your 
> program had at least one failure mode and one success mode you'd store 
> your return value in a variable and return it in the sole return-statement.

Yes, that is presumably what Malcolm meant by:

| In structured programming you can never have the line
|
| return EXIT_FAILURE;

but there's an exception:

  #include <stdlib.h>
  int main(void) { return EXIT_FAILURE; }

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#90134

"Ben Bacarisse" wrote:

> Gareth Owen <gwowen@gmail.com> writes:
>
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> I would look forward to your explanation of how that makes any sense
>>> at all (preferably, as Richard suggests, in a different thread)
>>> if I thought there was a reasonable chance of that happening.
>>
>> Well if thought "structured" meant "SESE in all circumstances", and your
>> program had at least one failure mode and one success mode you'd store
>> your return value in a variable and return it in the sole 
>> return-statement.
>
> Yes, that is presumably what Malcolm meant by:
>
> | In structured programming you can never have the line
> |
> | return EXIT_FAILURE;
>
> but there's an exception:
>
>  #include <stdlib.h>
>  int main(void) { return EXIT_FAILURE; }

Doesn't that depend on a distorted definition of the English word, failure? 
ISTM that the syntax is OK but the semantics are awful. 

[toc] | [prev] | [next] | [standalone]

#90135

"Osmium" <r124c4u102@comcast.net> writes:

> "Ben Bacarisse" wrote:
>
>> Gareth Owen <gwowen@gmail.com> writes:
>>
>>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>>> I would look forward to your explanation of how that makes any sense
>>>> at all (preferably, as Richard suggests, in a different thread)
>>>> if I thought there was a reasonable chance of that happening.
>>>
>>> Well if thought "structured" meant "SESE in all circumstances", and your
>>> program had at least one failure mode and one success mode you'd store
>>> your return value in a variable and return it in the sole
>>> return-statement.
>>
>> Yes, that is presumably what Malcolm meant by:
>>
>> | In structured programming you can never have the line
>> |
>> | return EXIT_FAILURE;
>>
>> but there's an exception:
>>
>>  #include <stdlib.h>
>>  int main(void) { return EXIT_FAILURE; }
>
> Doesn't that depend on a distorted definition of the English word,
> failure? ISTM that the syntax is OK but the semantics are awful.

Not sure what you mean.  If you want a command that always fails, this
is exactly the way to write it.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#90242

On 7/8/2016 3:34 PM, Ben Bacarisse wrote:
> "Osmium" <r124c4u102@comcast.net> writes:
>
>> "Ben Bacarisse" wrote:
[...]
>>> Yes, that is presumably what Malcolm meant by:
>>>
>>> | In structured programming you can never have the line
>>> |
>>> | return EXIT_FAILURE;
>>>
>>> but there's an exception:
>>>
>>>  #include <stdlib.h>
>>>  int main(void) { return EXIT_FAILURE; }
>>
>> Doesn't that depend on a distorted definition of the English word,
>> failure? ISTM that the syntax is OK but the semantics are awful.
>
> Not sure what you mean.  If you want a command that always fails, this
> is exactly the way to write it.

But doesn't it fail successfully?

:-)

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#90169

On Fri, 8 Jul 2016 14:25:29 -0500, "Osmium" <r124c4u102@comcast.net>
wrote:

>"Ben Bacarisse" wrote:
>
>> Gareth Owen <gwowen@gmail.com> writes:
>>
>>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>>> I would look forward to your explanation of how that makes any sense
>>>> at all (preferably, as Richard suggests, in a different thread)
>>>> if I thought there was a reasonable chance of that happening.
>>>
>>> Well if thought "structured" meant "SESE in all circumstances", and your
>>> program had at least one failure mode and one success mode you'd store
>>> your return value in a variable and return it in the sole 
>>> return-statement.
>>
>> Yes, that is presumably what Malcolm meant by:
>>
>> | In structured programming you can never have the line
>> |
>> | return EXIT_FAILURE;
>>
>> but there's an exception:
>>
>>  #include <stdlib.h>
>>  int main(void) { return EXIT_FAILURE; }
>
>Doesn't that depend on a distorted definition of the English word, failure? 
>ISTM that the syntax is OK but the semantics are awful. 


Isn't that basically the code for "false"?

[toc] | [prev] | [next] | [standalone]

#90185

"Osmium" <r124c4u102@comcast.net> writes:

> "Ben Bacarisse" wrote:
>
>> Gareth Owen <gwowen@gmail.com> writes:
>>
>>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>>> I would look forward to your explanation of how that makes any sense
>>>> at all (preferably, as Richard suggests, in a different thread)
>>>> if I thought there was a reasonable chance of that happening.
>>>
>>> Well if thought "structured" meant "SESE in all circumstances", and your
>>> program had at least one failure mode and one success mode you'd store
>>> your return value in a variable and return it in the sole
>>> return-statement.
>>
>> Yes, that is presumably what Malcolm meant by:
>>
>> | In structured programming you can never have the line
>> |
>> | return EXIT_FAILURE;
>>
>> but there's an exception:
>>
>>  #include <stdlib.h>
>>  int main(void) { return EXIT_FAILURE; }
>
> Doesn't that depend on a distorted definition of the English word,
> failure? ISTM that the syntax is OK but the semantics are awful. 

Of course, but programming is full of instances in which words and
symbols are used in distorted ways.

[toc] | [prev] | [next] | [standalone]

#90186

"Osmium" <r124c4u102@comcast.net> writes:
> "Ben Bacarisse" wrote:
[...]
>>  #include <stdlib.h>
>>  int main(void) { return EXIT_FAILURE; }
>
> Doesn't that depend on a distorted definition of the English word, failure? 
> ISTM that the syntax is OK but the semantics are awful. 

EXIT_SUCCESS and EXIT_FAILURE

    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

What distortion do you see?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#90187

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnoa65ksi8.fsf@kst-u.example.com...
> "Osmium" <r124c4u102@comcast.net> writes:
>> "Ben Bacarisse" wrote:
> [...]
>>>  #include <stdlib.h>
>>>  int main(void) { return EXIT_FAILURE; }
>>
>> Doesn't that depend on a distorted definition of the English word, 
>> failure?
>> ISTM that the syntax is OK but the semantics are awful.
>
> EXIT_SUCCESS and EXIT_FAILURE
>
>    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
>
> What distortion do you see?

The program was successful and did what it was designed to do and returned 
status indicating that it had failed.

If I misunderstood something, then I misunderstood something; so be it. 

[toc] | [prev] | [next] | [standalone]

#90188

"Osmium" <r124c4u102@comcast.net> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnoa65ksi8.fsf@kst-u.example.com...
>> "Osmium" <r124c4u102@comcast.net> writes:
>>> "Ben Bacarisse" wrote:
>> [...]
>>>>  #include <stdlib.h>
>>>>  int main(void) { return EXIT_FAILURE; }
>>>
>>> Doesn't that depend on a distorted definition of the English word, 
>>> failure?
>>> ISTM that the syntax is OK but the semantics are awful.
>>
>> EXIT_SUCCESS and EXIT_FAILURE
>>
>>    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
>>
>> What distortion do you see?
>
> The program was successful and did what it was designed to do and returned 
> status indicating that it had failed.

Yes.  I see that it's a bit odd, but it's quite useful (see /bin/false
on Unix).

> If I misunderstood something, then I misunderstood something; so be it. 

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#90191

On 07/10/2016 07:30 PM, Osmium wrote:
> 
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnoa65ksi8.fsf@kst-u.example.com...
>> "Osmium" <r124c4u102@comcast.net> writes:
>>> "Ben Bacarisse" wrote:
>> [...]
>>>>  #include <stdlib.h>
>>>>  int main(void) { return EXIT_FAILURE; }
>>>
>>> Doesn't that depend on a distorted definition of the English word, 
>>> failure?
>>> ISTM that the syntax is OK but the semantics are awful.
>>
>> EXIT_SUCCESS and EXIT_FAILURE
>>
>>    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
>>
>> What distortion do you see?
> 
> The program was successful and did what it was designed to do and returned 
> status indicating that it had failed.

What it was designed to do was return a status indicating that it had
failed. If it had returned EXIT_SUCCESS, that would have been a failure,
and therefore a lie. Have fun thinking about it :-)

> If I misunderstood something, then I misunderstood something; so be it. 

[toc] | [prev] | [next] | [standalone]

#90192

In article <nlv15a$724$1@dont-email.me>, James Kuyper <jameskuyper@verizon.net> 
wrote:

> What it was designed to do was return a status indicating that it had
> failed. If it had returned EXIT_SUCCESS, that would have been a failure,
> and therefore a lie. Have fun thinking about it :-)

How do I interpret BREXIT_SUCCESS?

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
If you assume the final scene is a dying delusion as Tom Cruise drowns below
the Louvre, then Edge of Tomorrow has a happy ending. Kill Tom repeat..

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web