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

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

main's return rule

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

Contents

  main's return rule fir <profesor.fir@gmail.com> - 2017-09-28 09:49 -0700
    Re: main's return rule fir <profesor.fir@gmail.com> - 2017-09-28 10:04 -0700
      Re: main's return rule fir <profesor.fir@gmail.com> - 2017-09-28 10:09 -0700
      Re: main's return rule fir <profesor.fir@gmail.com> - 2017-09-28 11:10 -0700
    Re: main's return rule Thomas David Rivers <rivers@dignus.com> - 2017-09-28 15:13 -0400
      Re: main's return rule Keith Thompson <kst-u@mib.org> - 2017-09-28 12:43 -0700
        Re: main's return rule Thomas David Rivers <rivers@dignus.com> - 2017-10-02 10:12 -0400
        Re: main's return rule herrmannsfeldt@gmail.com - 2017-12-10 13:54 -0800
          Re: main's return rule Keith Thompson <kst-u@mib.org> - 2017-12-10 14:39 -0800
            Re: main's return rule herrmannsfeldt@gmail.com - 2017-12-13 05:01 -0800
              Re: main's return rule Keith Thompson <kst-u@mib.org> - 2017-12-13 09:17 -0800
                Re: main's return rule scott@slp53.sl.home (Scott Lurndal) - 2017-12-13 18:31 +0000
                Re: main's return rule herrmannsfeldt@gmail.com - 2017-12-14 11:51 -0800
        Re: main's return rule Manfred <noname@invalid.add> - 2017-12-13 20:36 +0100
          Re: main's return rule "James R. Kuyper" <jameskuyper@verizon.net> - 2017-12-13 15:14 -0500
          Re: main's return rule supercat@casperkitty.com - 2017-12-14 07:47 -0800
            Re: main's return rule Manfred <noname@invalid.add> - 2017-12-14 20:18 +0100
      Re: main's return rule fir <profesor.fir@gmail.com> - 2017-09-29 07:50 -0700
        Re: main's return rule Chad <cdalten@gmail.com> - 2017-09-29 08:14 -0700
        Re: main's return rule gordonb.3z6ou@burditt.org (Gordon Burditt) - 2017-09-29 13:01 -0500

#120458 — main's return rule

small not but i forgot i thinked to mention 
that (and some may comment on that if they want)

there is as far as i realize a confusion what 
to return from main, (and also what return on succes and what on error)
afair the present rule is to ret 0 on succes and everything alse on error.. (which is unfortunatelly negation of common rules used for normal functions which are opposite 0 on fail non zero for succes) i just propose to change it (i mean main return value meaning)

the proposition is: return positive value on succes (including zero as positive) and return any negative on error

(it assumes that any system in which c is used alows to return signed integers on return - buts probably mostly true (are there any system that would not provide signed numbers onlu unsigned?)

[toc] | [next] | [standalone]

#120459

W dniu czwartek, 28 września 2017 18:49:28 UTC+2 użytkownik fir napisał:
> small not but i forgot i thinked to mention 

small not ==.* small note 

> that (and some may comment on that if they want)
> 
> there is as far as i realize a confusion what 
> to return from main, (and also what return on succes and what on error)
> afair the present rule is to ret 0 on succes and everything alse on error.. (which is unfortunatelly negation of common rules used for normal functions which are opposite 0 on fail non zero for succes) i just propose to change it (i mean main return value meaning)
> 
> the proposition is: return positive value on succes (including zero as positive) and return any negative on error
> 
> (it assumes that any system in which c is used alows to return signed integers on return - buts probably mostly true (are there any system that would not provide signed numbers onlu unsigned?)

it may provoke some other thought (it provoked may
when i thinked a bit on this)

this rule 0 on fail anything else on succes i think comes from how if works 

if(a) .... //for succes

or
if(!a) ..... //for error

coz it is nice to write this and it works naturalely

though sometimes especially when one seeks for offest in some array (which is quite common case) treating returned 0 as a succes would be quite nice, othervise i mast write 
if(id<0) or if(id==-1) etc wventually make one fake record in array (what i sometimes was doing)

this may yeild to conclusion that 0 could and maybe even should be treated as "true" same as 1 2 3 etc
only -1 (and consecutive -2 -3 etc) should be treated as false

and i may say im close to that solution/design

it would just mean that when speaking on binary there should be 2 values 0 and -1 not 0 and 1 more to say 0
should be treated as true (! :O)  and -1 should denote false
(this -1 i could also call "pole" or how to call it, know what i mean, its more to close to x/0 (inf) than just +1
 

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

#120460

W dniu czwartek, 28 września 2017 19:04:44 UTC+2 użytkownik fir napisał:
> W dniu czwartek, 28 września 2017 18:49:28 UTC+2 użytkownik fir napisał:
> > small not but i forgot i thinked to mention 
> 
> small not ==.* small note 
> 
> > that (and some may comment on that if they want)
> > 
> > there is as far as i realize a confusion what 
> > to return from main, (and also what return on succes and what on error)
> > afair the present rule is to ret 0 on succes and everything alse on error.. (which is unfortunatelly negation of common rules used for normal functions which are opposite 0 on fail non zero for succes) i just propose to change it (i mean main return value meaning)
> > 
> > the proposition is: return positive value on succes (including zero as positive) and return any negative on error
> > 
> > (it assumes that any system in which c is used alows to return signed integers on return - buts probably mostly true (are there any system that would not provide signed numbers onlu unsigned?)
> 
> it may provoke some other thought (it provoked may
> when i thinked a bit on this)
> 
> this rule 0 on fail anything else on succes i think comes from how if works 
> 
> if(a) .... //for succes
> 
> or
> if(!a) ..... //for error
> 
> coz it is nice to write this and it works naturalely
> 
> though sometimes especially when one seeks for offest in some array (which is quite common case) treating returned 0 as a succes would be quite nice, othervise i mast write 
> if(id<0) or if(id==-1) etc wventually make one fake record in array (what i sometimes was doing)
> 
> this may yeild to conclusion that 0 could and maybe even should be treated as "true" same as 1 2 3 etc
> only -1 (and consecutive -2 -3 etc) should be treated as false
> 
> and i may say im close to that solution/design
> 
> it would just mean that when speaking on binary there should be 2 values 0 and -1 not 0 and 1 more to say 0
> should be treated as true (! :O)  and -1 should denote false
> (this -1 i could also call "pole" or how to call it, know what i mean, its more to close to x/0 (inf) than just +1

it would also fit to such cases

if(a-b)...

(if a==b  a-b is equal to zero, subtraction is very close to comparing, it also would bring true if a>b 
which seems to be nice trick

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

#120468

W dniu czwartek, 28 września 2017 19:04:44 UTC+2 użytkownik fir napisał:
> W dniu czwartek, 28 września 2017 18:49:28 UTC+2 użytkownik fir napisał:
> > small not but i forgot i thinked to mention 
> 
> small not ==.* small note 
> 
> > that (and some may comment on that if they want)
> > 
> > there is as far as i realize a confusion what 
> > to return from main, (and also what return on succes and what on error)
> > afair the present rule is to ret 0 on succes and everything alse on error.. (which is unfortunatelly negation of common rules used for normal functions which are opposite 0 on fail non zero for succes) i just propose to change it (i mean main return value meaning)
> > 
> > the proposition is: return positive value on succes (including zero as positive) and return any negative on error
> > 
> > (it assumes that any system in which c is used alows to return signed integers on return - buts probably mostly true (are there any system that would not provide signed numbers onlu unsigned?)
> 
> it may provoke some other thought (it provoked may
> when i thinked a bit on this)
> 
> this rule 0 on fail anything else on succes i think comes from how if works 
> 
> if(a) .... //for succes
> 
> or
> if(!a) ..... //for error
> 
> coz it is nice to write this and it works naturalely
> 
> though sometimes especially when one seeks for offest in some array (which is quite common case) treating returned 0 as a succes would be quite nice, othervise i mast write 
> if(id<0) or if(id==-1) etc wventually make one fake record in array (what i sometimes was doing)
> 
> this may yeild to conclusion that 0 could and maybe even should be treated as "true" same as 1 2 3 etc
> only -1 (and consecutive -2 -3 etc) should be treated as false
> 
> and i may say im close to that solution/design
> 
> it would just mean that when speaking on binary there should be 2 values 0 and -1 not 0 and 1 more to say 0
> should be treated as true (! :O)  and -1 should denote false
> (this -1 i could also call "pole" or how to call it, know what i mean, its more to close to x/0 (inf) than just +1

yet thinking of it it seems that 
1)-1 is in fact problematic 
2) it should be not named -1 
(couse for example if one would have 4-state variable it would be logical to name such states as

0
+1
-1
inf

it is seen that inf is not -1)

so it could be thinkaed as 0 and a or 0 and i  or 0 and inf  or how to call it

still it seems that 0 should mean true

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

#120479

fir wrote:

>small not but i forgot i thinked to mention 
>that (and some may comment on that if they want)
>
>there is as far as i realize a confusion what 
>to return from main, (and also what return on succes and what on error)
>afair the present rule is to ret 0 on succes and everything alse on error.. (which is unfortunatelly negation of common rules used for normal functions which are opposite 0 on fail non zero for succes) i just propose to change it (i mean main return value meaning)
>
>the proposition is: return positive value on succes (including zero as positive) and return any negative on error
>
>(it assumes that any system in which c is used alows to return signed integers on return - buts probably mostly true (are there any system that would not provide signed numbers onlu unsigned?)
>
>
>  
>
The return code from main() in many environments becomes the returned
status for the program reported by the operating system.

In some operating systems, the operating system only allows for 0 or 
small positive
integers as the "return value" from an executing program.

Thus - the convention in those operating systems (outside the scope of 
C) is that
0 is success, non-zero is failure.

Hence the C convention for the return code of main() - 0 is "good", 
non-zero is "not as good".

For example - see the definition of the POSIX wait() function, and in 
particular
the WEXITSTATUS value.  In a UNIX/Linux/POSIX environment the operating 
system
restricts the return value to an unsigned 8-bit value... so, if main() 
returns -1, the
value presented by the operation system will be 255.     Check out this 
link:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html

-- 
rivers@dignus.com                        Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

#120484

Thomas David Rivers <rivers@dignus.com> writes:
[...]
> Hence the C convention for the return code of main() - 0 is "good", 
> non-zero is "not as good".
[...]

That's not a convention that's defined by the C standard, and there
are systems that follow different conventions.  C requires that
returning 0 or EXIT_SUCCESS denotes success, returning EXIT_FAILURE
denotes failure, and returning any other value has an unspecified
meaning.

Unix-like systems do follow the "zero good, non-zero bad" convenion.
I think MS Windows does too.  OpenVMS, for example, does not.

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

#120696

Keith Thompson wrote:

>Thomas David Rivers <rivers@dignus.com> writes:
>[...]
>  
>
>>Hence the C convention for the return code of main() - 0 is "good", 
>>non-zero is "not as good".
>>    
>>
>[...]
>
>That's not a convention that's defined by the C standard, and there
>are systems that follow different conventions.  C
>
Yeah - it's really outside of the C standard...  just trying
to motivate the reasons for EXIT_SUCCESS/EXIT_FAILURE...

   - Dave R. -

-- 
rivers@dignus.com                        Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

#124109

On Thursday, September 28, 2017 at 12:43:52 PM UTC-7, Keith Thompson wrote:

(snip)
> That's not a convention that's defined by the C standard, and there
> are systems that follow different conventions.  C requires that
> returning 0 or EXIT_SUCCESS denotes success, returning EXIT_FAILURE
> denotes failure, and returning any other value has an unspecified
> meaning.

> Unix-like systems do follow the "zero good, non-zero bad" convenion.
> I think MS Windows does too.  OpenVMS, for example, does not.

I thought OpenVMS did also, but in addition it has specific error
messages that go with some return codes.

The IBM tradition (at least since OS/360) is for return codes to
be multiples of 4, (I suspect to use in branch tables).

I had a program that, following that tradition, did an exit(8).

The code from OpenVMS, ACCVIO access violation, surprised me.

VMS has

HELP/MESSAGE/STATUS=xx

which will translate a number to a message.

It does seem that 1 is normal exit, and there is no
message for 0.

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

#124113

herrmannsfeldt@gmail.com writes:
> On Thursday, September 28, 2017 at 12:43:52 PM UTC-7, Keith Thompson wrote:
[...]
>> Unix-like systems do follow the "zero good, non-zero bad" convenion.
>> I think MS Windows does too.  OpenVMS, for example, does not.
>
> I thought OpenVMS did also, but in addition it has specific error
> messages that go with some return codes.

The VMS/OpenVMS convention, as I recall, is that odd return codes denote
success and even codes denote failure.

Since the C standard specifically requires 0 to denote success, the C
runtime maps 0 to 1 -- but it doesn't map 1 to 0.

[...]

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

#124280

On Sunday, December 10, 2017 at 2:40:07 PM UTC-8, Keith Thompson wrote:

(snip, I wrote)
> > I thought OpenVMS did also, but in addition it has specific error
> > messages that go with some return codes.

> The VMS/OpenVMS convention, as I recall, is that odd return codes denote
> success and even codes denote failure.

help/message/status=xx

returns error messages for some odd values, but it looks like
the same message for some even values.

I don't know where to find a table, but keep putting in
different values, and looking at the result.

> Since the C standard specifically requires 0 to denote success, the C
> runtime maps 0 to 1 -- but it doesn't map 1 to 0.

$ help/message/status=55

 BADATTRIB,  bad attribute control list

  Facility:     SYSTEM, System Services

  Explanation:  An invalid code or size is specified in the read or write
                attribute list for a file system ACP QIO function.

  User Action:  Check for a programming error. Begin debugging procedures to
                verify the source of the problem and to correct the problem.

                Note that when using ANSI-standard magnetic tapes, the block
                size must be 4 bytes larger than the largest record in a
                variable record length file, and the largest record that can
                be written is 2048 bytes. To write files larger than 2048
                bytes, mount the tape using the /BLOCKSIZE qualifier.

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

#124294

herrmannsfeldt@gmail.com writes:
> On Sunday, December 10, 2017 at 2:40:07 PM UTC-8, Keith Thompson wrote:
> (snip, I wrote)
>> > I thought OpenVMS did also, but in addition it has specific error
>> > messages that go with some return codes.
>
>> The VMS/OpenVMS convention, as I recall, is that odd return codes denote
>> success and even codes denote failure.
>
> help/message/status=xx
>
> returns error messages for some odd values, but it looks like
> the same message for some even values.
>
> I don't know where to find a table, but keep putting in
> different values, and looking at the result.

I'd be glad to try it if I still had access to a VMS system.

>> Since the C standard specifically requires 0 to denote success, the C
>> runtime maps 0 to 1 -- but it doesn't map 1 to 0.
>
> $ help/message/status=55
>
>  BADATTRIB,  bad attribute control list
>
>   Facility:     SYSTEM, System Services
>
>   Explanation:  An invalid code or size is specified in the read or write
>                 attribute list for a file system ACP QIO function.
>
>   User Action:  Check for a programming error. Begin debugging procedures to
>                 verify the source of the problem and to correct the problem.
>
>                 Note that when using ANSI-standard magnetic tapes, the block
>                 size must be 4 bytes larger than the largest record in a
>                 variable record length file, and the largest record that can
>                 be written is 2048 bytes. To write files larger than 2048
>                 bytes, mount the tape using the /BLOCKSIZE qualifier.

Hmm, that's odd, and also odd.  A quick Google search turns up this,
which tends to confirm my memory of odd vs. even status codes:

    If you specify a status code, DCL interprets the code as a condition
    code. Note that even numeric values produce warning, error, and
    fatal error messages, and that odd numeric values produce either no
    message or a success or informational message.

http://h41379.www4.hpe.com/doc/84final/9996/9996pro_165.html

(It's referring to DCL, not to C, but they should use the same convention.)

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

#124297

Keith Thompson <kst-u@mib.org> writes:
>herrmannsfeldt@gmail.com writes:
>> On Sunday, December 10, 2017 at 2:40:07 PM UTC-8, Keith Thompson wrote:
>> (snip, I wrote)
>>> > I thought OpenVMS did also, but in addition it has specific error
>>> > messages that go with some return codes.
>>
>>> The VMS/OpenVMS convention, as I recall, is that odd return codes denote
>>> success and even codes denote failure.
>>
>> help/message/status=xx
>>
>> returns error messages for some odd values, but it looks like
>> the same message for some even values.
>>
>> I don't know where to find a table, but keep putting in
>> different values, and looking at the result.
>
>I'd be glad to try it if I still had access to a VMS system.

Well, SS$_NORMAL had the value 1, which is consistent with
"odd return codes denote success".   But in fact, anything
other than SS$_NORMAL requires extra scrutiny by well-written
software.

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

#124334

On Wednesday, December 13, 2017 at 9:17:24 AM UTC-8, Keith Thompson wrote:

(snip)

> I'd be glad to try it if I still had access to a VMS system.

http://www.livingcomputers.org/Discover/Online-Systems/Request-a-Login.aspx

You can get a free account on an 11/785 running VMS 7.3.

If you like Unix, there is SVR3 or v7, same form.

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

#124301

On 9/28/2017 9:43 PM, Keith Thompson wrote:
> Thomas David Rivers <rivers@dignus.com> writes:
> [...]
>> Hence the C convention for the return code of main() - 0 is "good",
>> non-zero is "not as good".
> [...]
> 
> That's not a convention that's defined by the C standard, and there
> are systems that follow different conventions.  C requires that
> returning 0 or EXIT_SUCCESS denotes success, returning EXIT_FAILURE
> denotes failure, and returning any other value has an unspecified
> meaning.

And I think there is a good reason for the "zero-good, non-zero bad" 
convention:
A success condition is self-defined for the system, the OS only needs to 
know that the program completed as expected, as any other result is 
provided to the user/caller by the application interface: stdout, 
display, socket, carrier pigeon, whatever.
Therefore a success condition requires a single identifier to get 
identified - zero is a sensible choice for a single distinct integer.

A failure may be due to a number of reasons (including the process not 
being able to start at all), the OS may want to do something about it, 
and/or the application interface may be not functional, so that the only 
reliable process output may be its return code.
Hence the need for multiple failure exit codes.

In other words, from the system perspective, unlike the user/caller, 
there is little interest in a success condition compared to a failure 
condition.

> 
> Unix-like systems do follow the "zero good, non-zero bad" convenion.
> I think MS Windows does too.  OpenVMS, for example, does not.
> 
I am not familiar with OPenVMS, but I would guess that still it uses a 
single code for success and a variety of codes for failure, am I wrong?

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

#124302

On 12/13/2017 02:36 PM, Manfred wrote:
> On 9/28/2017 9:43 PM, Keith Thompson wrote:
>> Thomas David Rivers <rivers@dignus.com> writes:
>> [...]
>>> Hence the C convention for the return code of main() - 0 is "good",
>>> non-zero is "not as good".
>> [...]
>>
>> That's not a convention that's defined by the C standard, and there
>> are systems that follow different conventions.  C requires that
>> returning 0 or EXIT_SUCCESS denotes success, returning EXIT_FAILURE
>> denotes failure, and returning any other value has an unspecified
>> meaning.
> 
> And I think there is a good reason for the "zero-good, non-zero bad"
> convention:
> A success condition is self-defined for the system, the OS only needs to
> know that the program completed as expected, as any other result is
> provided to the user/caller by the application interface: stdout,
> display, socket, carrier pigeon, whatever.
> Therefore a success condition requires a single identifier to get
> identified - zero is a sensible choice for a single distinct integer.
> 
> A failure may be due to a number of reasons (including the process not
> being able to start at all), the OS may want to do something about it,
> and/or the application interface may be not functional, so that the only
> reliable process output may be its return code.
> Hence the need for multiple failure exit codes.
> 
> In other words, from the system perspective, unlike the user/caller,
> there is little interest in a success condition compared to a failure
> condition.
> 
>>
>> Unix-like systems do follow the "zero good, non-zero bad" convenion.
>> I think MS Windows does too.  OpenVMS, for example, does not.
>>
> I am not familiar with OPenVMS, but I would guess that still it uses a
> single code for success and a variety of codes for failure, am I wrong?

Yes, you are wrong. It reserves all even values for reporting a variety 
of different error codes, and it reserves all odd values for reporting a 
variety of success codes. That is a pretty direct counter-example to 
your hypothesis. However, it's also not a particularly common OS, which 
reduces the weight of that counter-example.

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

#124325

On Wednesday, December 13, 2017 at 1:37:12 PM UTC-6, Manfred wrote:
> And I think there is a good reason for the "zero-good, non-zero bad" 
> convention:
> A success condition is self-defined for the system, the OS only needs to 
> know that the program completed as expected, as any other result is 
> provided to the user/caller by the application interface: stdout, 
> display, socket, carrier pigeon, whatever.
> Therefore a success condition requires a single identifier to get 
> identified - zero is a sensible choice for a single distinct integer.

There are, however, also many cases where code may need to distinguish
among multiple "good" conditions as well as error conditions.  As a simple
example, consider a basic file-compare operation.  There are, at minimum,
two distinct successful conditions as well as a distinct failure condition:

   1. Files exist, are readable, and have matching content (success #1)
   2. Files exist, are readable, and have different content (success #2)
   3. Network drive containing files is inaccessible (failure)

Situations where files can be determined to definitely not exist may be
viewed as success or failure, depending upon the purpose of the client
code, but a situation where the network drive can't be accessed is almost
certainly considered a failure.

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

#124333

On 12/14/2017 4:47 PM, supercat@casperkitty.com wrote:
> On Wednesday, December 13, 2017 at 1:37:12 PM UTC-6, Manfred wrote:
>> And I think there is a good reason for the "zero-good, non-zero bad"
>> convention:
>> A success condition is self-defined for the system, the OS only needs to
>> know that the program completed as expected, as any other result is
>> provided to the user/caller by the application interface: stdout,
>> display, socket, carrier pigeon, whatever.
>> Therefore a success condition requires a single identifier to get
>> identified - zero is a sensible choice for a single distinct integer.
> 
> There are, however, also many cases where code may need to distinguish
> among multiple "good" conditions as well as error conditions.  As a simple
> example, consider a basic file-compare operation.  There are, at minimum,
> two distinct successful conditions as well as a distinct failure condition:
> 
>     1. Files exist, are readable, and have matching content (success #1)
>     2. Files exist, are readable, and have different content (success #2)
>     3. Network drive containing files is inaccessible (failure)
> 
> Situations where files can be determined to definitely not exist may be
> viewed as success or failure, depending upon the purpose of the client
> code, but a situation where the network drive can't be accessed is almost
> certainly considered a failure.
> 

True, and in fact my previous post was making too hard of a statement. 
Probably I should have limited to the consideration that, from a systems 
perspective (and hence WRT the code returned to the OS), the distinction 
between different success conditions is of less interest than for failures.

The scenario I had in mind was more of the kind of e.g. init starting 
services: in this scenario init (the OS) does not care /how/ such 
services start running, but instead /if/ they start running successfully 
(and log something or do anything appropriate if not)

Back to your cmp example, while it is of course appropriate, it might 
trigger some more considerations:
At a first glance, I might regard file comparison as more of an 
application domain action than a system domain one (although exceptions 
are always possible)
More to the point, depending on context, case 2 might be regarded as a 
failure as well (although nothing was broken, the equality test still 
failed), and if this be the case, you could use cmp directly as an 
argument to an 'if' shell command:
if cmp file1 file2; then echo OK; else echo NOK; fi

Obviously it all depends on context, bottomline, I think, is that if a 
more fine-grained control is wanted on the result, then probably the 
result itself goes somehow beyond the basic classification of "success" 
and "failure" only.

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

#120541

W dniu czwartek, 28 września 2017 21:11:11 UTC+2 użytkownik Thomas David Rivers napisał:
> fir wrote:
> 
> >small not but i forgot i thinked to mention 
> >that (and some may comment on that if they want)
> >
> >there is as far as i realize a confusion what 
> >to return from main, (and also what return on succes and what on error)
> >afair the present rule is to ret 0 on succes and everything alse on error.. (which is unfortunatelly negation of common rules used for normal functions which are opposite 0 on fail non zero for succes) i just propose to change it (i mean main return value meaning)
> >
> >the proposition is: return positive value on succes (including zero as positive) and return any negative on error
> >
> >(it assumes that any system in which c is used alows to return signed integers on return - buts probably mostly true (are there any system that would not provide signed numbers onlu unsigned?)
> >
> >
> >  
> >
> The return code from main() in many environments becomes the returned
> status for the program reported by the operating system.
> 
> In some operating systems, the operating system only allows for 0 or 
> small positive
> integers as the "return value" from an executing program.
> 
> Thus - the convention in those operating systems (outside the scope of 
> C) is that
> 0 is success, non-zero is failure.
> 
> Hence the C convention for the return code of main() - 0 is "good", 
> non-zero is "not as good".
> 
> For example - see the definition of the POSIX wait() function, and in 
> particular
> the WEXITSTATUS value.  In a UNIX/Linux/POSIX environment the operating 
> system
> restricts the return value to an unsigned 8-bit value... so, if main() 
> returns -1, the
> value presented by the operation system will be 255.     Check out this 
> link:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html
> 
ye i heard that rule and i think that rule is wrong
return 0 1 2 3 .... for succes
return -1 -2 -3 for fail


(this returning is useless anyway,m but holding to more sane rule makes imo program looking a bit more 
of quality)

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

#120542

On Friday, September 29, 2017 at 7:50:55 AM UTC-7, fir wrote:
> W dniu czwartek, 28 września 2017 21:11:11 UTC+2 użytkownik Thomas David Rivers napisał:
> > fir wrote:
> > 
> > >small not but i forgot i thinked to mention 
> > >that (and some may comment on that if they want)
> > >
> > >there is as far as i realize a confusion what 
> > >to return from main, (and also what return on succes and what on error)
> > >afair the present rule is to ret 0 on succes and everything alse on error.. (which is unfortunatelly negation of common rules used for normal functions which are opposite 0 on fail non zero for succes) i just propose to change it (i mean main return value meaning)
> > >
> > >the proposition is: return positive value on succes (including zero as positive) and return any negative on error
> > >
> > >(it assumes that any system in which c is used alows to return signed integers on return - buts probably mostly true (are there any system that would not provide signed numbers onlu unsigned?)
> > >
> > >
> > >  
> > >
> > The return code from main() in many environments becomes the returned
> > status for the program reported by the operating system.
> > 
> > In some operating systems, the operating system only allows for 0 or 
> > small positive
> > integers as the "return value" from an executing program.
> > 
> > Thus - the convention in those operating systems (outside the scope of 
> > C) is that
> > 0 is success, non-zero is failure.
> > 
> > Hence the C convention for the return code of main() - 0 is "good", 
> > non-zero is "not as good".
> > 
> > For example - see the definition of the POSIX wait() function, and in 
> > particular
> > the WEXITSTATUS value.  In a UNIX/Linux/POSIX environment the operating 
> > system
> > restricts the return value to an unsigned 8-bit value... so, if main() 
> > returns -1, the
> > value presented by the operation system will be 255.     Check out this 
> > link:
> > 
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html
> > 
> ye i heard that rule and i think that rule is wrong
> return 0 1 2 3 .... for succes
> return -1 -2 -3 for fail
> 
> 
> (this returning is useless anyway,m but holding to more sane rule makes imo program looking a bit more 
> of quality)

No. I could post some code that was written by a former AOL and Mozilla Software Engineer that could prove you have no idea what you're talking about. But given the fact that you pretty much suck dick at programming, well, I'd suspect you wouldn't understand this person's code.

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

#120558

>> For example - see the definition of the POSIX wait() function, and in 
>> particular
>> the WEXITSTATUS value.  In a UNIX/Linux/POSIX environment the operating 
>> system
>> restricts the return value to an unsigned 8-bit value... so, if main() 
>> returns -1, the
>> value presented by the operation system will be 255.     Check out this 
>> link:
>> 
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html
>> 
> ye i heard that rule and i think that rule is wrong

It's hard to claim a rule is wrong just because you don't like it.
Claiming the rule is wrong because it's not the real rule is OK,
but that's not the case here.  

Your proposed rule is wrong because it doesn't work, at least under
UNIX / POSIX.  Windows uses 32-bit unsigned exit codes, and MS-DOS
uses 8-bit unsigned errorlevels, so it wouldn't work for them either.

In spite of the type of main() - int - which would make you think
that you can return at least a signed 16-bit integer, the status
made available is actually only 8 bits.  And some of the shells use
the high-order bit of those 8 bits to communicate termination of
the program by a signal rather than with exit() or returning from
main().

> return 0 1 2 3 .... for succes
> return -1 -2 -3 for fail

This might have been a good idea for a design from the start, but
existing systems have way too many roadblocks to using it.

If you return -2 from main(), it looks like a status of 254 in the
Bourne shell (that is, the termination status variable $? will have
the value 254), and the documentation says that this means the
program was terminated by signal (254-128) = signal 126.  Other
shells followed the same interpretation.  I don't know of any POSIX
system that actually has that many signals, though, but nobody says
you have to number them consecutively starting from 1.


> (this returning is useless anyway,m but holding to more sane
rule makes imo program looking a bit more 
> of quality)

Exit statuses are far from useless.  Classification of all of them
into "success" or "failure" is often a bit clumsy.  One man's "success"
may be a higher-level "failure", for example, successfully opening
a file may be a "failure", at least in that you have to prompt
the user "File %s already exists.  Are you Shirley you want to
overwrite?"

There are some conventions to handle multiple types of "success",
for example, in a group of programs I'll call "file comparison"
programs", a status of 0 means the files successfully compared
equal, 1 means the files successfully compared unequal, and 2 means
the comparison failed, perhaps because one of the files does not
exist, permission problems, the file name was not given on the
command line, running out of memory, I/O error reading the files,
etc.  Programs that follow this include cmp, diff, rcsdiff, sccsdiff,
etc.

[toc] | [prev] | [standalone]

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

csiph-web