Re: main's return rule

From	Keith Thompson <kst-u@mib.org>
Newsgroups	comp.lang.c
Subject	Re: main's return rule
Date	2017-12-13 09:17 -0800
Organization	None to speak of
Message-ID	<lnd13io8df.fsf@kst-u.example.com> (permalink)
References	(1 earlier) <59CD49ED.7030101@dignus.com> <lnbmluwqvj.fsf@kst-u.example.com> <505425da-b024-4a06-ab30-c1b211a26cd1@googlegroups.com> <lnindeqkaq.fsf@kst-u.example.com> <2961429c-4de3-4086-be7d-2fb7f971e547@googlegroups.com>

Show all headers | View raw

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"

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