Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000957 [1003.1(2013)/Issue7+TC1] Base Definitions and Headers Editorial Enhancement Request 2015-06-10 17:41 2016-04-07 16:03
Reporter steffen View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name Steffen Nurpmeso
Organization
User Reference
Section XSH, stdlib.h
Page Number 358
Line Number 12037
Interp Status ---
Final Accepted Text
Summary 0000957: Add an extended set of exit status codes
Description The ISO C(99) standard only defines the EXIT_SUCCESS (0) and EXIT_FAILURE (only seen as 1) constants as symbolic exit status codes.

These are insufficient to express many real-life use cases, causing other digits in the usable 8-bit range to be selected rather randomly; e.g., -1 (or 255) is commonly used to manifest a fatal program error.

Many systems and scripting languages offer (at least optionally) a set of extended exit status codes that is based upon the BSD /usr/include/sysexits.h constants.
This header was first created on 1981-10-15 (by Eric Allman), and gained only three new constants over time: EX_TEMPFAIL (1981-10-15), EX_PROTOCOL (1982-08-29) and EX_NOPERM (1983-07-31).
It can thus be seen as a mature interface.
Desired Action Add symbolic exit status codes with the same values that are known for this long time, but with ISO C compatible names and in the same place as the usual ISO C status codes.

On page 358, insert, after line 12037

[CX]
EXIT_USAGE
        The command was used incorrectly, e.g., with the wrong number of
        arguments, a bad flag, a bad syntax in a parameter, or whatever.
EXIT_DATAERR
        The input data was incorrect in some way. This should only be used for
        user's data & not system files.
EXIT_NOINPUT
        An input file (not a system file) did not exist or was not readable.
        This could also include errors like "No message" to a mailer (if it
        cared to catch it).
EXIT_NOUSER
        The user specified did not exist. This might be used for mail addresses
        or remote logins.
EXIT_NOHOST
        The host specified did not exist. This is used in mail addresses or
        network requests.
EXIT_UNAVAILABLE
        A service is unavailable. This can occur if a support program or file
        does not exist. This can also be used as a catchall message when
        something you wanted to do doesn't work, but you don't know why.
EXIT_SOFTWARE
        An internal software error has been detected. This should be limited to
        non-operating system related errors as possible.
EXIT_OSERR
        An operating system error has been detected. This is intended to be
        used for such things as "cannot fork", "cannot create pipe", or the
        like. It includes things like getuid returning a user that does not
        exist in the passwd database.
EXIT_OSFILE
        Some system file does not exist, cannot be opened, or has some sort of
        error (e.g., syntax error).
EXIT_CANTCREAT
        A (user specified) output file cannot be created.
EXIT_IOERR
        An error occurred while doing I/O on some file.
EXIT_TEMPFAIL
        Temporary failure, indicating something that is not really an error. In
        sendmail, this means that a mailer (e.g.) could not create a connection,
        and the request should be reattempted later.
EXIT_PROTOCOL
        The remote system returned something that was "not possible" during
        a protocol exchange.
EXIT_NOPERM
        You did not have sufficient permission to perform the operation. This
        is not intended for file system problems, which should use EXIT_NOINPUT
        or EXIT_CANTCREAT, but rather for higher level permissions.
EXIT__BASE, EXIT__MAX
        The base and maximum value used for the extended POSIX status code
        sequence.
[/CX]
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0002704)
shware_systems (reporter)
2015-06-10 22:11

The standard already reserves error codes 126 to 255 inclusive as defined errors, along with EXIT_SUCCESS and EXIT_FAILURE. Language restricting these suggested values to somewhere in the 2 to 125 range, and as a contiguous block, seems appropriate.
(0002705)
steffen (reporter)
2015-06-11 11:49

Yes, it seems to be a larger issue than i thought.
And then it would maybe be better to give symbolic names to 126 (EXIT_NOEXEC) and 127 (EXIT_NOENT), too.
And yes, EXIT__BASE should definitely be defined to be 64, the same value that "it" always had.

Doing so would have a large impact on the standard text... (And a lot of manual duplications on those special values 126 and 127 could be changed to be instead references to the symbolic names; that alone should probably be reason enough to add those constants.)

It seems so half-baked if we have all those named errno(3) constants on the low level but fiddle with numeric constants in higher levels, like shell scripts; even kind of bizarre.
(0003138)
rhansen (manager)
2016-04-07 16:02

Since the standard does not reserve EXIT_ as a prefix for <stdlib.h>, adding these symbols to that header could potentially break existing applications. In addition, no known implementation defines those constants in <stdlib.h>. It may be reasonable to standardize <sysexits.h> as-is, but this would require sponsorship and no organization was willing to sponsor that addition.

Additional concerns about the usage of these identifiers in portable applications (both shell scripts and C code), were brought up and in some cases seen as requiring invention to accommodate:
  • There is no way provided for an application to translate an exit value into a meaningful description of why that value was returned (there is no analogue to strerror()).
  • There is no guarantee that two applications using these exit codes would get agreement on the values returned by cooperating processes on different systems unless the values were included in the standard.
  • No way was suggested by the submitter to reserve namespaces for additional constants to be added by implementations in the future with consistent values.
  • It is unclear whether the standard utilities would have to be modified to use these values, or avoid the use of values in the range EXIT__BASE to EXIT__MAX for unrelated causes.

- Issue History
Date Modified Username Field Change
2015-06-10 17:41 steffen New Issue
2015-06-10 17:41 steffen Name => Steffen Nurpmeso
2015-06-10 17:41 steffen Section => XSH, stdlib.h
2015-06-10 17:41 steffen Page Number => 358
2015-06-10 17:41 steffen Line Number => 12037
2015-06-10 22:11 shware_systems Note Added: 0002704
2015-06-11 11:49 steffen Note Added: 0002705
2016-04-07 16:02 rhansen Note Added: 0003138
2016-04-07 16:03 rhansen Interp Status => ---
2016-04-07 16:03 rhansen Status New => Closed
2016-04-07 16:03 rhansen Resolution Open => Rejected


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker