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

Groups > comp.lang.c > #120479

Re: main's return rule

Show all headers | View raw

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

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web