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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#90194

Siri Cruise <chine.bleu@yahoo.com> wrote:

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

As a black comedy.

Richard

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

#90244

On 7/11/2016 1:31 AM, Siri Cruise wrote:
> 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?

Re-partition "/dev/europe" into separate filesystems.

-- 
Kenneth Brody

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

#90190

In article <lnoa65ksi8.fsf@kst-u.example.com>,
Keith Thompson  <kst-u@mib.org> wrote:
>"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?

Wow.  Just wow.

As with most Kiki posts.

Wow.  Just wow.

-- 
I've been watching cat videos on YouTube.  More content and closer to
the truth than anything on Fox.

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

#90306

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

When you try to fit English words to computer programming concepts, things
often get distorted.

As near as I can tell, an implementation is allowed to define other
exit statuses like:

EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE
EXIT_SUCCESS_YOU_GET_TO_KEEP_YOUR_JOB
EXIT_SUCCESS_YOU_ARE_DEMOTED_TO_SEWAGE_TASTER
EXIT_FAILURE_TRUMP_SAYS_YOURE_FIRED
EXIT_FAILURE_YOURE_GOING_TO_JAIL
EXIT_FAILURE_YOU_WILL_BE_EXECUTED

but I don't know of any that do.

(I'm not sure whether the reserved identifiers beginning with E
followed by an underscore or capital letter for error codes in
<errno.h> would let you, as a C compiler author, put definitions
for the above in <stdlib.h>).

However, using the UNIX convention of 0 being success and all else being
failure, there really isn't a way to have more than one success code.
MS-DOS is a bit oriented towards 0 being success and higher numbers
indicate increasingly severe errors.

There are times when I wish UNIX adopted the VMS exit code approach:
odd statuses were considered success, even statuses were failures,
and the other bits indicated subcategories.  (No, I do not want to
make the same change to the C if () statement.) I do not think it
is a good idea to come up with a master list of error codes unrelated
to the program which generated them.  A good percentage (e.g. at
least half) should be definable by the programmer writing the program
that generates them.

"success" and "failure" of a program can have meaning at many
different levels.  For example, there are a series of Unix programs
that roughly do a "file compare", or compare groups of files.
Examples of these programs include cmp, diff, rcsdiff, sccsdiff,
and zipcmp.  There are 3 possible results:

0       The files compare equal.  This need not mean "files identical",
	as some of the file compare programs have options to ignore
	whitespace differences or other differences (e.g. keyword
	expansion) considered insignificant by the user.

1	The files compare unequal.  This includes files of unequal length
	even if the files are equal up to the point where the shorter
	file ends.  1 is a "failure" under UNIX because we've only got
	one success code, 0.

>1	Something bad happened, and the comparison was not made.
	(e.g. file does not exist, file permissions problem, two
	files were not given as arguments, the program ran out of
	memory, the command line uses incorrect options, disk i/o
	errors, etc.)

Most everyone considers the last group to be a "failure".

The "files unequal" group might be a "failure" if you are comparing
what you wrote and what you read back from removable media.

The "files equal" group might be a "failure" because the patch
you applied clearly didn't "take".

Pretty much every error has an equal and opposite error.  For
"File does not exist" there is "File exists" (your program might
want to refuse to write over an existing file).  For "Unbalanced
Parentheses" there is "Balanced Parentheses". For "Checksum error"
there is "No checksum error" (in a program which checks the
checksum-checking hardware).  For "Syntax Error" there is "No Syntax
Error" (in a compiler test suite). 

The mail delivery agent sendmail created a header file <sysexits.h>
(not a C standard header) containing (in the version I have handy)
15 different classes of reasons why the program sendmail called to
deliver your mail didn't deliver it.  It's general enough to apply
to many system programs, especially those that work in the background
with essentially no user interface, and some of the codes are
appropriate for networking.

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

#90307

On 07/12/2016 07:52 PM, Gordon Burditt wrote:
...
> As near as I can tell, an implementation is allowed to define other
> exit statuses like:
> 
> EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE
> EXIT_SUCCESS_YOU_GET_TO_KEEP_YOUR_JOB
> EXIT_SUCCESS_YOU_ARE_DEMOTED_TO_SEWAGE_TASTER
> EXIT_FAILURE_TRUMP_SAYS_YOURE_FIRED
> EXIT_FAILURE_YOURE_GOING_TO_JAIL
> EXIT_FAILURE_YOU_WILL_BE_EXECUTED
> 
> but I don't know of any that do.

My CentOS Linux desktop machine at work has /usr/local/sysexits.h, which
declares specific exit status codes for every value from 64 to 77. I'm
not sure it's provenance - but it contains a comment saying

@(#)sysexits.h  8.1 (Berkeley) 6/2/93

suggesting that it's associated with BSD. You mention sysexits.h farther
down in your message, so why do you say "I don't know of any that do."?

<https://en.wikipedia.org/wiki/Exit_status#OpenVMS> indicates that VMS
status codes are very structured:  "success is indicated by odd values
and failure by even values. The value is a 32 bit integer with
sub-fields: control bits, facility number, message number and severity.
Severity values are divided between success (Success, Informational) and
failure (Warning, Error, Fatal)." That's consistent with what I remember
of VMS (which, after 20 years, isn't much). I don't know of any easy way
to check right now, but I would expect that there's some macros #defined
in some header corresponding to valid values for each of those fields.

> (I'm not sure whether the reserved identifiers beginning with E
> followed by an underscore or capital letter for error codes in
> <errno.h> would let you, as a C compiler author, put definitions
> for the above in <stdlib.h>).

Those names are "... reserved no matter what headers are included by the
program" (7.31p1), which gives you sufficient freedom to do so, but
7.13.3 says such identifiers "... may be added to the macros defined in
the <errno.h> header.". The standard is very clear about the conformance
implications of "reserved" - it's not so clear about "may be".

The sysexits.h macros all start with "EX_".

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

#90308

"James R. Kuyper" <jameskuyper@verizon.net> writes:

> On 07/12/2016 07:52 PM, Gordon Burditt wrote:
> ...
>> As near as I can tell, an implementation is allowed to define other
>> exit statuses like:
>> 
>> EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE
>> EXIT_SUCCESS_YOU_GET_TO_KEEP_YOUR_JOB
>> EXIT_SUCCESS_YOU_ARE_DEMOTED_TO_SEWAGE_TASTER
>> EXIT_FAILURE_TRUMP_SAYS_YOURE_FIRED
>> EXIT_FAILURE_YOURE_GOING_TO_JAIL
>> EXIT_FAILURE_YOU_WILL_BE_EXECUTED
>> 
>> but I don't know of any that do.
>
> My CentOS Linux desktop machine at work has /usr/local/sysexits.h, which
> declares specific exit status codes for every value from 64 to 77. I'm
> not sure it's provenance - but it contains a comment saying

That's a file I'd never noticed before -- thanks.  That looks *really*
useful.

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

#90309

>> As near as I can tell, an implementation is allowed to define other
>> exit statuses like:
>> 
>> EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE
>> EXIT_SUCCESS_YOU_GET_TO_KEEP_YOUR_JOB
>> EXIT_SUCCESS_YOU_ARE_DEMOTED_TO_SEWAGE_TASTER
>> EXIT_FAILURE_TRUMP_SAYS_YOURE_FIRED
>> EXIT_FAILURE_YOURE_GOING_TO_JAIL
>> EXIT_FAILURE_YOU_WILL_BE_EXECUTED
>> 
>> but I don't know of any that do.
> 
> My CentOS Linux desktop machine at work has /usr/local/sysexits.h, which

That's a strange location for a C header file:  are you sure it's
not /usr/local/include/sysexits.h or /usr/include/sysexits.h?  Can
you access it with #include <sysexits.h>  without giving the compiler
a -I option or setting environment variables?

> declares specific exit status codes for every value from 64 to 77. I'm
> not sure it's provenance - but it contains a comment saying

> @(#)sysexits.h  8.1 (Berkeley) 6/2/93

My version, on FreeBSD 10, has that SCCS stamp (same version, same
date, which is from 4.4BSD Sendmail 8.1 a few days before the 4.4BSD
freeze) along with a FreeBSD RCS-like header with a date of 2010-02-16.
My version has EX_CONFIG (value 78, "Configuration Error") in
addition to the ones you mention.  Most modification of system
header files is changing the copyright notice.  A recent version
of sendmail is 8.15.2, released in July 2015 (per Wikipedia).

> suggesting that it's associated with BSD. You mention sysexits.h farther
> down in your message, so why do you say "I don't know of any that do."?

The implementation didn't put them in standard C headers (like
<stdlib.h>) alongside EXIT_FAILURE and EXIT_SUCCESS.  The header
started out as part of a userland program (sendmail), not part of
the implementation.  It shouldn't have used symbols of the form
EX_* as a userland program, but it was written pre-C89 and first
shipped with BSD 4.1c in 1983.

Also, I still know of no implementation that uses exit status codes
as a replacement for a HR department.

> <https://en.wikipedia.org/wiki/Exit_status#OpenVMS> indicates that VMS
> status codes are very structured:  "success is indicated by odd values
> and failure by even values. The value is a 32 bit integer with
> sub-fields: control bits, facility number, message number and severity.
> Severity values are divided between success (Success, Informational) and
> failure (Warning, Error, Fatal)." That's consistent with what I remember
> of VMS (which, after 20 years, isn't much). I don't know of any easy way
> to check right now, but I would expect that there's some macros #defined
> in some header corresponding to valid values for each of those fields.

I don't mind structure to status codes, but I don't like the OS locking
down almost all of them.  A status code communicates between a program and
its invokers, and that includes a program used to throw up a dialog
box and get a user response (FreeBSD has such a program, used among other
places during system installation.  It gives shell scripts a GUI
appearance.)  

<sysexits.h> exit codes are great for background programs with no
or almost no user interface, such as daemons.  They aren't so great
for interactive and GUI programs.  They aren't really suitable for
compilers, either.  What, for example, should a compiler use as a
status code for defining a typedef which is already defined?

>> (I'm not sure whether the reserved identifiers beginning with E
>> followed by an underscore or capital letter for error codes in
>> <errno.h> would let you, as a C compiler author, put definitions
>> for the above in <stdlib.h>).
> 
> Those names are "... reserved no matter what headers are included by the
> program" (7.31p1), which gives you sufficient freedom to do so, but
> 7.13.3 says such identifiers "... may be added to the macros defined in
> the <errno.h> header.". The standard is very clear about the conformance
> implications of "reserved" - it's not so clear about "may be".
> 
> The sysexits.h macros all start with "EX_".

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

#90331

On 07/13/2016 03:11 AM, Gordon Burditt wrote:

As I have repeatedly told you - you do not have permission to quote my
words without proper attribution. I understand your ridiculous worry
that you'll be held responsible for the inaccuracy of the attribution if
you happen to respond to a forged message. It has repeatedly been
brought to your attention that you can meet your obligation to provide
proper attribution, without incurring responsibility for the possible of
a forged name, by using a phrase such as "Someone claiming to be ...".
When do you plan to start using that approach? I don't believe you've
ever given a reason for not using it.

...
>> My CentOS Linux desktop machine at work has /usr/local/sysexits.h, which
> 
> That's a strange location for a C header file:  are you sure it's
> not /usr/local/include/sysexits.h or /usr/include/sysexits.h?  Can

That was hand-typed, and I accidentally left out the include/ part.

...
>> declares specific exit status codes for every value from 64 to 77. I'm
>> not sure it's provenance - but it contains a comment saying
> 
>> @(#)sysexits.h  8.1 (Berkeley) 6/2/93
> 
> My version, on FreeBSD 10, has that SCCS stamp (same version, same
> date, which is from 4.4BSD Sendmail 8.1 a few days before the 4.4BSD
> freeze) along with a FreeBSD RCS-like header with a date of 2010-02-16.
> My version has EX_CONFIG (value 78, "Configuration Error") in
> addition to the ones you mention.

So does mine - that was a typo. There's a reason why I strongly favor
language features that cause common typos to become diagnosable errors.

...
> Also, I still know of no implementation that uses exit status codes
> as a replacement for a HR department.

???

>> <https://en.wikipedia.org/wiki/Exit_status#OpenVMS> indicates that VMS
>> status codes are very structured:  "success is indicated by odd values
>> and failure by even values. The value is a 32 bit integer with
>> sub-fields: control bits, facility number, message number and severity.
>> Severity values are divided between success (Success, Informational) and
>> failure (Warning, Error, Fatal)." That's consistent with what I remember
>> of VMS (which, after 20 years, isn't much). I don't know of any easy way
>> to check right now, but I would expect that there's some macros #defined
>> in some header corresponding to valid values for each of those fields.
> 
> I don't mind structure to status codes, but I don't like the OS locking
> down almost all of them.

I'm not sure it does. Notice the "message number" field. I don't know
whether VMS assigns specific meanings to every possible message number -
I do know that it's commonplace in other, similar contexts, to reserve
some of the numbers for user-defined meanings.

...
> <sysexits.h> exit codes are great for background programs with no
> or almost no user interface, such as daemons.  They aren't so great
> for interactive and GUI programs.  They aren't really suitable for
> compilers, either.  What, for example, should a compiler use as a
> status code for defining a typedef which is already defined?

POSIX guarantees that the lower eight bits of the value passed to exit()
will be the lower eight bits of the status code passed back to the
parent process. That's 256 different possible values - sysexits.h only
#defines 15 of them - most the rest are available for user-defined
meanings. I remember that many of the low-numbered values have a
POSIX-defined meaning, but I have searched the POSIX standard without
locating where it says so.

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

#90332

James Kuyper <jameskuyper@verizon.net> writes:
> On 07/13/2016 03:11 AM, Gordon Burditt wrote:
>> James Kuyper <jameskuyper@verizon.net>, as Gordon Burditt foolishly
>> refused to acknowledge, wrote:
[...]
>>> My CentOS Linux desktop machine at work has /usr/local/sysexits.h, which
>> 
>> That's a strange location for a C header file:  are you sure it's
>> not /usr/local/include/sysexits.h or /usr/include/sysexits.h?  Can
>
> That was hand-typed, and I accidentally left out the include/ part.

On the CentOS 5.11 system I'm using at the moment, it's
/usr/include/sysexits.h.  There is no /usr/local/include/sysexits.h.

[...]

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

#90519

"James R. Kuyper" <jameskuyper@verizon.net> writes:

> On 07/12/2016 07:52 PM, Gordon Burditt wrote:
> ...
>> As near as I can tell, an implementation is allowed to define other
>> exit statuses like:
>>
>> EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE
>> EXIT_SUCCESS_YOU_GET_TO_KEEP_YOUR_JOB
>> EXIT_SUCCESS_YOU_ARE_DEMOTED_TO_SEWAGE_TASTER
>> EXIT_FAILURE_TRUMP_SAYS_YOURE_FIRED
>> EXIT_FAILURE_YOURE_GOING_TO_JAIL
>> EXIT_FAILURE_YOU_WILL_BE_EXECUTED
>>
>> but I don't know of any that do.
>
> My CentOS Linux desktop machine at work has /usr/local/sysexits.h, which
> declares specific exit status codes for every value from 64 to 77.  I'm
> not sure its provenance - but it contains a comment saying
>
> @(#)sysexits.h  8.1 (Berkeley) 6/2/93
>
> suggesting that its associated with BSD.  You mention sysexits.h farther
> down in your message, so why do you say "I don't know of any that do."?
>
> <https://en.wikipedia.org/wiki/Exit_status#OpenVMS> indicates that VMS
> status codes are very structured:  "success is indicated by odd values
> and failure by even values.  The value is a 32 bit integer with
> sub-fields:  control bits, facility number, message number and severity.
> Severity values are divided between success (Success, Informational) and
> failure (Warning, Error, Fatal)."  That's consistent with what I remember
> of VMS (which, after 20 years, isn't much).  I don't know of any easy way
> to check right now, but I would expect that there's some macros #defined
> in some header corresponding to valid values for each of those fields.
>
>> (I'm not sure whether the reserved identifiers beginning with E
>> followed by an underscore or capital letter for error codes in
>> <errno.h> would let you, as a C compiler author, put definitions
>> for the above in <stdlib.h>).
>
> Those names are "... reserved no matter what headers are included by the
> program" (7.31p1), [...]

This conclusion is not correct.  The macros defined in <errno.h>
(and those mentioned in 7.31.3) are reserved only if <errno.h>
has been #include'd.  The quoted sentence fragment above applies
only to external names.  The names of macros like those defined
in <errno.h> (and similarly 7.31.3) are not external names.

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

#90136

On 07/08/2016 01:03 PM, Gareth Owen wrote:
> 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.

One of my first significant programming projects involved trying to make
a minor change to a text-based computer game written in spaghetti Basic,
that was deliberately padded to come out to exactly 1000 lines of code.
My first paid programming job involved unraveling a big ball of
spaghetti Fortran code. At around the same time I was taking a course in
C, and they taught structured programming techniques, and with those two
examples in mind, it was easy to convince me of the merits of the idea.
However, as it says at
<https://en.wikipedia.org/wiki/Structured_programming#Early_exit>, "The
most common deviation from structured programming is early exit from a
function or loop.", and I'm a strong believer in that deviation. The
hoops you sometimes have to jump through (such as that variable you
mention) to satisfy "SESE in all circumstances" are just not worth it.

Exception: Whenever it can conveniently be arranged, I will make sure
that there's only one free(p) for every p=malloc(), and that the free()
occurs inside of an if(p) block, and there there's absolutely no way to
avoid the free() once that block has been entered - which means, in
particular, no early exits. This is not always feasible, but when it can
be done, it greatly reduces memory leaks and double-free() errors. I try
to do the same for other kinds of bookend code, such as fopen()/fclose().

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

#90155

ram@zedat.fu-berlin.de (Stefan Ram) writes:
[...]
>   Yesterday, in my Java course, I showed this example and
>   asked the participiants what it will print. (Should be
>   readable for C programmers. I just translated it into
>   English for this post.)
>
> public final class Main
> {
>   public static java.lang.String english( final int a )
>   { java.lang.String result;
>     if( a == 0 )result = "zero";
>     if( a == 1 )result = "one";
>     if( a == 2 )result = "two";
>     if( a == 3 )result = "three";
>     else        result = "four"; 
>     return result; }
[...]
>   Everyone said »zero, one, two, three, four«.
>
>   But it will print »four, four, four, three, four«.
[...]

In this particular case a switch statement is the obvious solution, but
that doesn't generalize as well.

A better solution is:

    if      (a == 0) result = "zero";
    else if (a == 1) result = "one";
    else if (a == 2) result = "two";
    else if (a == 3) result = "three";
    else             result = "four";
    return result;

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

#90965

Keith Thompson wrote:
> A better solution is:
>     if      (a == 0) result = "zero";
>     else if (a == 1) result = "one";
>     else if (a == 2) result = "two";
>     else if (a == 3) result = "three";
>     else             result = "four";
>     return result;

If you want to do multiple ifs like that, I prefer to do:
    result = "four";              // default
    if (a == 0) result = "zero"; 
    if (a == 1) result = "one";
    if (a == 2) result = "two";
    if (a == 3) result = "three";
    return result;

jgh

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

#90970

On 25/07/16 12:42, jgh@mdfs.net wrote:
> Keith Thompson wrote:
>> A better solution is:
>>      if      (a == 0) result = "zero";
>>      else if (a == 1) result = "one";
>>      else if (a == 2) result = "two";
>>      else if (a == 3) result = "three";
>>      else             result = "four";
>>      return result;
>
> If you want to do multiple ifs like that, I prefer to do:
>      result = "four";              // default
>      if (a == 0) result = "zero";
>      if (a == 1) result = "one";
>      if (a == 2) result = "two";
>      if (a == 3) result = "three";
>      return result;

static const char *get_foo(size_t a)
{
   static const char *numbers[] =
   {
     "zero",
     "one",
     "two",
     "three",
     "four"
   };
   size_t maxval = sizeof numbers / sizeof numbers[0] - 1;

   return numbers[a <= maxval ? a : maxval];
}

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

#90998

On Monday 25 July 2016 05:37 PM, Richard Heathfield wrote:
> static const char *get_foo(size_t a)
> {
>   static const char *numbers[] =
>   {
>     "zero",
>     "one",
>     "two",
>     "three",
>     "four"
>   };
>   size_t maxval = sizeof numbers / sizeof numbers[0] - 1;
> 
>   return numbers[a <= maxval ? a : maxval];
> }

What good code.

At what point does knowledge of the language of implementation affect
the code of the solution?  How much of the process of solution is
independent of the language?

Presumably, the more experienced the programmer with a language, the
more he thinks in the language, and the more the solution emerges in the
language itself within the mind of the programmer.

-- 
Udyant Wig

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

#91018

Richard Heathfield <rjh@cpax.org.uk> wrote:

> On 25/07/16 12:42, jgh@mdfs.net wrote:

> static const char *get_foo(size_t a)
> {
>    static const char *numbers[] =
>    {
>      "zero",
>      "one",
>      "two",
>      "three",
>      "four"
>    };
>    size_t maxval = sizeof numbers / sizeof numbers[0] - 1;
> 
>    return numbers[a <= maxval ? a : maxval];
> }

A good solution, but it only works well if the accepted values of a are
contiguous (or nearly so, with at most a handful of ugly extra defaults
scattered through the array).

Richard

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

#91032

On 25/07/16 17:06, Richard Bos wrote:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> On 25/07/16 12:42, jgh@mdfs.net wrote:
>
>> static const char *get_foo(size_t a)
>> {
>>     static const char *numbers[] =
>>     {
>>       "zero",
>>       "one",
>>       "two",
>>       "three",
>>       "four"
>>     };
>>     size_t maxval = sizeof numbers / sizeof numbers[0] - 1;
>>
>>     return numbers[a <= maxval ? a : maxval];
>> }
>
> A good solution,

A slightly better solution (which, of course, I thought of /after/ 
posting) would have been to make maxval static.

> but it only works well if the accepted values of a are
> contiguous (or nearly so, with at most a handful of ugly extra defaults
> scattered through the array).

That's right. I fitted the solution to the problem. If the problem 
changes, sometimes the solution changes too (for example, to a perfect 
hash or even some kind of dictionary).

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

#91041

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 25/07/16 17:06, Richard Bos wrote:
>> Richard Heathfield <rjh@cpax.org.uk> wrote:
>>
>>> On 25/07/16 12:42, jgh@mdfs.net wrote:
>>
>>> static const char *get_foo(size_t a)
>>> {
>>>     static const char *numbers[] =
>>>     {
>>>       "zero",
>>>       "one",
>>>       "two",
>>>       "three",
>>>       "four"
>>>     };
>>>     size_t maxval = sizeof numbers / sizeof numbers[0] - 1;
>>>
>>>     return numbers[a <= maxval ? a : maxval];
>>> }
>>
>> A good solution,
>
> A slightly better solution (which, of course, I thought of /after/ 
> posting) would have been to make maxval static.

And const?

[...]

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

#91042

On 25/07/16 19:04, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 25/07/16 17:06, Richard Bos wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> wrote:
>>>
>>>> On 25/07/16 12:42, jgh@mdfs.net wrote:
>>>
>>>> static const char *get_foo(size_t a)
>>>> {
>>>>      static const char *numbers[] =
>>>>      {
>>>>        "zero",
>>>>        "one",
>>>>        "two",
>>>>        "three",
>>>>        "four"
>>>>      };
>>>>      size_t maxval = sizeof numbers / sizeof numbers[0] - 1;
>>>>
>>>>      return numbers[a <= maxval ? a : maxval];
>>>> }
>>>
>>> A good solution,
>>
>> A slightly better solution (which, of course, I thought of /after/
>> posting) would have been to make maxval static.
>
> And const?

Yep. I thought of that one after posting the one I thought of after 
posting the first one. Shades of IEFBR14.

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

#91059

On 25/07/2016 19:14, Richard Heathfield wrote:
> On 25/07/16 19:04, Keith Thompson wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:

>>>>>      size_t maxval = sizeof numbers / sizeof numbers[0] - 1;
>>>>>      return numbers[a <= maxval ? a : maxval];

>>> A slightly better solution (which, of course, I thought of /after/
>>> posting) would have been to make maxval static.
>>
>> And const?
>
> Yep. I thought of that one after posting the one I thought of after
> posting the first one. Shades of IEFBR14.

So:

  static const size_t maxval = ...

before you've even started expressing the size of the array?

I might go with:

#define LEN(a) (sizeof (a)/sizeof ((a)[0]))
#define UPB(a) (LEN(a)-1)
...
       return numbers[a <= UPB(numbers) ? a : UPB(numbers)];

or:
       return numbers[a < LEN(numbers) ? a : (LEN(numbers)-1)];


-- 
Bartc

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web