Hello everyone,

I'm wondering why, at least on Linux and FreeBSD, a process exit
status was chosen to be only the lower 8 bits in the C interface, i.e.
exit() and wait().

This did bite some colleagues at work at one point who were porting a
modem manager from a real-time OS to Linux because they were returning
negative status codes for errors. We fixed it by changing the status
codes and I never really thought about why this is the state of
things... until now!

Having a look at man 3 exit on my FreeBSD system, it states

>Both functions make the low-order eight bits of the status argument
>available to a parent process which has called a wait(2)-family
>function.

and that it is conforming to the C99 standard

> The exit() and _Exit() functions conform to ISO/IEC 9899:1999
> (“ISO C99”).

C99 7.20.4.3 § 5 states

> Finally, control is returned to the host environment. If the value of
> status is zero or EXIT_SUCCESS, an implementation-defined form of the
> status successful termination is returned. If the value of status is
> EXIT_FAILURE, an implementation-defined form of the status
> unsuccessful termination is returned. Otherwise the status returned
> is implementation-defined.

which I read as the C standard leaving it to the implementation to
decide how to handle the int type argument.

Having a look at man 2 _exit, the system call man page, it says
nothing about the lower 8 bits, but claims conformance with
IEEE Std 1003.1-1990 ("POSIX.1") which says
in Part 1: System Application Program Interface (API) [C Language], 3.2.2.2 § 2

> If the parent process of the calling process is executing a wait() or
> waitpid(), it is notified of the termination of the calling process
> and the low order 8 bits of status are made available to it; see
> 3.2.1.

that only puts a requirement on making the lower 8 bits available.
Looking at a more modern POSIX, IEEE Std 1003.1-2017, that has
waitid() defined, it has the following for _exit()

> The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any
> other value, though only the least significant 8 bits (that is,
> status & 0377) shall be available from wait() and waitpid(); the
> full value shall be available from waitid() and in the siginfo_t
> passed to a signal handler for SIGCHLD.

so the mystery of why the implementation is the way it is was
dispelled.

The question that remains is what the rationale behind using the lower
8 bits was from the start? Is it historical legacy that no one wanted
to change for backwards compatibility? Is there no need for exit codes
larger than 8 bits?

I don't know if I have ever come into contact with software that deals
with status codes that actually looks at the full value. My daily
driver shell, fish, certainly does not.

--
Best regards,
Andreas Kempe

Andreas Kempe <kempe@lysator.liu.se> writes:
>Hello everyone,
>
>I'm wondering why, at least on Linux and FreeBSD, a process exit
>status was chosen to be only the lower 8 bits in the C interface, i.e.
>exit() and wait().
>
<snip>

>The question that remains is what the rationale behind using the lower
>8 bits was from the start? Is it historical legacy that no one wanted
>to change for backwards compatibility? Is there no need for exit codes
>larger than 8 bits?

The definition of the wait system call. Recall that the
PDP-11 was a 16-bit computer and wait needed to be able
to include metadata along with the exit status.

Den 2024-02-02 skrev Scott Lurndal <scott@slp53.sl.home>:
> Andreas Kempe <kempe@lysator.liu.se> writes:
>>Hello everyone,
>>
>>I'm wondering why, at least on Linux and FreeBSD, a process exit
>>status was chosen to be only the lower 8 bits in the C interface, i.e.
>>exit() and wait().
>>
> <snip>
>
>>The question that remains is what the rationale behind using the lower
>>8 bits was from the start? Is it historical legacy that no one wanted
>>to change for backwards compatibility? Is there no need for exit codes
>>larger than 8 bits?
>
> The definition of the wait system call. Recall that the
> PDP-11 was a 16-bit computer

I'm afraid that's a tall order. I had yet to learn how to read when
they went out of production. :) Please excuse my ignorance.

> and wait needed to be able to include metadata along with the exit
> status.

I'm a bit unclear on the order of things coming into being. Did their
C implementation already use exit() with an int argument of size 16
bits and they also masked? Or was an int 8 bits on PDP-11 with POSIX
opting mask out the lower 8 bits on platforms with wider ints to
maintain backwards compatibility?

Andreas Kempe <kempe@lysator.liu.se> writes:
>Den 2024-02-02 skrev Scott Lurndal <scott@slp53.sl.home>:
>> Andreas Kempe <kempe@lysator.liu.se> writes:
>>>Hello everyone,
>>>
>>>I'm wondering why, at least on Linux and FreeBSD, a process exit
>>>status was chosen to be only the lower 8 bits in the C interface, i.e.
>>>exit() and wait().
>>>
>> <snip>
>>
>>>The question that remains is what the rationale behind using the lower
>>>8 bits was from the start? Is it historical legacy that no one wanted
>>>to change for backwards compatibility? Is there no need for exit codes
>>>larger than 8 bits?
>>
>> The definition of the wait system call. Recall that the
>> PDP-11 was a 16-bit computer
>
>I'm afraid that's a tall order. I had yet to learn how to read when
>they went out of production. :) Please excuse my ignorance.
>
>> and wait needed to be able to include metadata along with the exit
>> status.
>
>I'm a bit unclear on the order of things coming into being. Did their
>C implementation already use exit() with an int argument of size 16
>bits and they also masked? Or was an int 8 bits on PDP-11 with POSIX
>opting mask out the lower 8 bits on platforms with wider ints to
>maintain backwards compatibility?

The status argument to the wait system call returned
a two part value; 8 bits of exit status and 8 bits
that describe the termination conditions (e.g. the
signal number that stopped or terminated the
process).

Here's the modern 32-bit layout (in little endian form):

unsigned int __w_termsig:7; /* Terminating signal. */
unsigned int __w_coredump:1; /* Set if dumped core. */
unsigned int __w_retcode:8; /* Return code if exited normally. */
unsigned int:16;

It's just the PDP-11 unix 16-bit version with 16 unused padding bits.

SVR4 added the waitid(2) system call which via the siginfo argument has
access to the full 32-bit program exit status.

On Fri, 2 Feb 2024 16:05:14 -0000 (UTC), Andreas Kempe wrote:

> I'm wondering why, at least on Linux and FreeBSD, a process exit status
> was chosen to be only the lower 8 bits in the C interface, i.e.
> exit() and wait().

I’ve never used that many different values. E.g. 0 for some test condition
passed, 1 for failed, 2 for unexpected error.

> This did bite some colleagues at work at one point who were porting a
> modem manager from a real-time OS to Linux because they were returning
> negative status codes for errors.

True enough:

ldo@theon:~> python3 -c "import sys; sys.exit(1)"; echo $?
1
ldo@theon:~> python3 -c "import sys; sys.exit(-1)"; echo $?
255

But you could always sign-extend it.

Den 2024-02-02 skrev Scott Lurndal <scott@slp53.sl.home>:
> Andreas Kempe <kempe@lysator.liu.se> writes:
>>I'm a bit unclear on the order of things coming into being. Did their
>>C implementation already use exit() with an int argument of size 16
>>bits and they also masked? Or was an int 8 bits on PDP-11 with POSIX
>>opting mask out the lower 8 bits on platforms with wider ints to
>>maintain backwards compatibility?
>
> The status argument to the wait system call returned
> a two part value; 8 bits of exit status and 8 bits
> that describe the termination conditions (e.g. the
> signal number that stopped or terminated the
> process).
>
>
> Here's the modern 32-bit layout (in little endian form):
>
> unsigned int __w_termsig:7; /* Terminating signal. */
> unsigned int __w_coredump:1; /* Set if dumped core. */
> unsigned int __w_retcode:8; /* Return code if exited normally. */
> unsigned int:16;
>
> It's just the PDP-11 unix 16-bit version with 16 unused padding bits.
>

Thank you for the clarification, but I don't think I have any problem
grasping how the implementation works. My thought are why they did
what they did.

Why not use a char in exit() instead of int, with wait() returning the
full 16 bits? If the program itself fills in the upper 8 bits, it
makes sense, but otherwise I don't understand from an API perspective
why one would use a data type with the caveat that only half is used.

If we already have exit() and wait() using ints and want to stuff our
extra information in there without changing the API, it also makes
sense.

> SVR4 added the waitid(2) system call which via the siginfo argument has
> access to the full 32-bit program exit status.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Fri, 2 Feb 2024 16:05:14 -0000 (UTC), Andreas Kempe wrote:
>
>> I'm wondering why, at least on Linux and FreeBSD, a process exit status
>> was chosen to be only the lower 8 bits in the C interface, i.e.
>> exit() and wait().
>
> I’ve never used that many different values. E.g. 0 for some test condition
> passed, 1 for failed, 2 for unexpected error.

The curl command defines nearly 100 error codes ("man curl" for
details). That's the most I've seen. 8 bits is almost certainly
plenty if the goal is to enumerate specific error conditions.
It's not enough if you want to pass more information through the
error code, which is why most programs don't try to do that.

Since int is typically 32 bits (but only guaranteed by C to be at
least 16), the exit() function could theoretically be used to pass
32 bits of information, but that's not really much more useful than 8
bits. If a program needs to return more than 8 bits of information,
it will typically print a string to stdout or something similar.

(On Plan 9, a program's exit status is (was?) a string, empty for
success, a description of the error condition on error. It's a cool
idea, but I can imagine it introducing some interesting problems.)

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Fri, 02 Feb 2024 13:23:52 -0800, Keith Thompson wrote:

> The curl command defines nearly 100 error codes ("man curl" for
> details). That's the most I've seen.

Another reason for staying away from curl, I would say. It needlessly
replicates the functionality of a whole lot of different protocol clients,
when all you need is HTTP/HTTPS (maybe FTP/FTPS as well). That’s why I
stick to wget.

> (On Plan 9, a program's exit status is (was?) a string, empty for
> success, a description of the error condition on error. It's a cool
> idea, but I can imagine it introducing some interesting problems.)

What, not a JSON object?

On Fri, 2 Feb 2024 21:20:22 -0000 (UTC), Andreas Kempe wrote:

> Why not use a char in exit() instead of int, with wait() returning the
> full 16 bits? If the program itself fills in the upper 8 bits, it makes
> sense, but otherwise I don't understand from an API perspective why one
> would use a data type with the caveat that only half is used.

The other half contains information like whether the low half is actually
an explicit exit code, or something else like a signal that killed the
process. Or an indication that the process has not actually terminated,
but is just stopped.

Andreas Kempe <kempe@lysator.liu.se> writes:
> Den 2024-02-02 skrev Scott Lurndal <scott@slp53.sl.home>:
>> Andreas Kempe <kempe@lysator.liu.se> writes:
>>>I'm a bit unclear on the order of things coming into being. Did their
>>>C implementation already use exit() with an int argument of size 16
>>>bits and they also masked? Or was an int 8 bits on PDP-11 with POSIX
>>>opting mask out the lower 8 bits on platforms with wider ints to
>>>maintain backwards compatibility?
>>
>> The status argument to the wait system call returned
>> a two part value; 8 bits of exit status and 8 bits
>> that describe the termination conditions (e.g. the
>> signal number that stopped or terminated the
>> process).
>>
>>
>> Here's the modern 32-bit layout (in little endian form):
>>
>> unsigned int __w_termsig:7; /* Terminating signal. */
>> unsigned int __w_coredump:1; /* Set if dumped core. */
>> unsigned int __w_retcode:8; /* Return code if exited normally. */
>> unsigned int:16;
>>
>> It's just the PDP-11 unix 16-bit version with 16 unused padding bits.
>>
>
> Thank you for the clarification, but I don't think I have any problem
> grasping how the implementation works. My thought are why they did
> what they did.
>
> Why not use a char in exit() instead of int, with wait() returning the
> full 16 bits? If the program itself fills in the upper 8 bits, it
> makes sense, but otherwise I don't understand from an API perspective
> why one would use a data type with the caveat that only half is used.

C tends to use int values even for character data (when not an element
of a string). See for example the return types of getchar(), fgetc(),
et al, and even the type of character constants ('x' is of type int, not
char).

In early C, int was in many ways a kind of default type. Functions with
no visible declaration were assumed to return int. The signedness of
plain char is implementation-defined. Supporting exit values from 0 to
255 is fairly reasonable. Using an int to store that value is also
fairly reasonable -- especially since main() returns int, and exit(n) is
very nearly equivalent to return n in main().

Ignoring all but the low-order 8 bits is not specified by C. Non-POSIX
systems can use all 32 (or 16, or ...) bits of the return value.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Den 2024-02-03 skrev Keith Thompson <Keith.S.Thompson+u@gmail.com>:
> Andreas Kempe <kempe@lysator.liu.se> writes:
>>
>> Why not use a char in exit() instead of int, with wait() returning the
>> full 16 bits? If the program itself fills in the upper 8 bits, it
>> makes sense, but otherwise I don't understand from an API perspective
>> why one would use a data type with the caveat that only half is used.
>
> C tends to use int values even for character data (when not an element
> of a string). See for example the return types of getchar(), fgetc(),
> et al, and even the type of character constants ('x' is of type int, not
> char).
>

I thought the reason for the int return type was to have an error code
outside of the range of the valid data, with EOF being defined as
being a negative integer. A reason that isn't applicable for the
argument passing to exit by a program.

> In early C, int was in many ways a kind of default type. Functions with
> no visible declaration were assumed to return int. The signedness of
> plain char is implementation-defined.

I realised that char was a bad example just as I posted. I should have
chosen unsigned char instead.

> Supporting exit values from 0 to 255 is fairly reasonable. Using an
> int to store that value is also fairly reasonable -- especially
> since main() returns int, and exit(n) is very nearly equivalent to
> return n in main(). Ignoring all but the low-order 8 bits is not
> specified by C. Non-POSIX systems can use all 32 (or 16, or ...)
> bits of the return value.
>

Yes, in my original post, I detailed that the restriction does not
come from the C standard, but from POSIX. I'm not sure which came
first.

If C was first with having an exit() function and an int return for
main, I can imagine that it went something like this

- C chooses int for main
- C uses int in exit() to match main
- OS folks want to store extra data in the exit status, but they
want to match the C API
- let's just stuff it in the upper bits and keep the API the same with
an imposed restriction on the value in POSIX

or POSIX exit() was constructed with the int from main in mind, or it
could just be, as you point out, that int is a nice default integer
type and there wasn't much thought put into it beyond that.

I can speculate a bunch different reasons, but I'm curious if anyone
knows what the actual reasoning was.

On 03.02.2024 14:21, Andreas Kempe wrote:
> Den 2024-02-03 skrev Keith Thompson <Keith.S.Thompson+u@gmail.com>:
>> Andreas Kempe <kempe@lysator.liu.se> writes:
>>>
>>> Why not use a char in exit() instead of int, with wait() returning the
>>> full 16 bits? If the program itself fills in the upper 8 bits, it
>>> makes sense, but otherwise I don't understand from an API perspective
>>> why one would use a data type with the caveat that only half is used.
>>
>> C tends to use int values even for character data (when not an element
>> of a string). See for example the return types of getchar(), fgetc(),
>> et al, and even the type of character constants ('x' is of type int, not
>> char).
>>
>
> I thought the reason for the int return type was to have an error code
> outside of the range of the valid data, with EOF being defined as
> being a negative integer. A reason that isn't applicable for the
> argument passing to exit by a program.
>
>> In early C, int was in many ways a kind of default type. Functions with
>> no visible declaration were assumed to return int. The signedness of
>> plain char is implementation-defined.
>
> I realised that char was a bad example just as I posted. I should have
> chosen unsigned char instead.
>
>> Supporting exit values from 0 to 255 is fairly reasonable. Using an
>> int to store that value is also fairly reasonable -- especially
>> since main() returns int, and exit(n) is very nearly equivalent to
>> return n in main(). Ignoring all but the low-order 8 bits is not
>> specified by C. Non-POSIX systems can use all 32 (or 16, or ...)
>> bits of the return value.
>>
>
> Yes, in my original post, I detailed that the restriction does not
> come from the C standard, but from POSIX. I'm not sure which came
> first.
>
> If C was first with having an exit() function and an int return for
> main, I can imagine that it went something like this
>
> - C chooses int for main
> - C uses int in exit() to match main
> - OS folks want to store extra data in the exit status, but they
> want to match the C API
> - let's just stuff it in the upper bits and keep the API the same with
> an imposed restriction on the value in POSIX
>
> or POSIX exit() was constructed with the int from main in mind, or it
> could just be, as you point out, that int is a nice default integer
> type and there wasn't much thought put into it beyond that.
>
> I can speculate a bunch different reasons, but I'm curious if anyone
> knows what the actual reasoning was.

AFAICT; "historical reasons". You have some bits to carry some exit
status, some bits to carry other termination information (signals),
optionally some more bits to carry other supplementary information.
If you want that information all carried across a single primitive
data type you have to draw a line somewhere. Given that these days
one can not assume that more than 16 bit in the default 'int' type
guaranteed it seems quite obvious to split at 8 bit. (For practical
reasons differentiating 255 error codes seems more than enough, if
we consider what evaluating and individually acting on all of them
at the calling/environment level would mean.)

Janis

Andreas Kempe <kempe@lysator.liu.se> writes:
>Den 2024-02-03 skrev Keith Thompson <Keith.S.Thompson+u@gmail.com>:
>> Andreas Kempe <kempe@lysator.liu.se> writes:

>Yes, in my original post, I detailed that the restriction does not
>come from the C standard, but from POSIX. I'm not sure which came
>first.

The restriction predates both. It was how unix v6 worked; every
version of unix thereafter continued that so that existing applications
would not need to be rewritten.

It was documented in the SVID (System V Interface Definition) which
was part of the source materials used by X/Open when developing
the X Portability Guides (xpg) (which became the SuS).

Ken and Dennis chose to implement the wait system call (which
the shell uses to collect the exit status) with an 8-bit value
so they could use the other 8 bits of the 16-bit int for metadata.

This could never be changed without breaking applications, so
we still have it today in unix, linux and other POSIX-compliant
operating evironments.

On Fri, 02 Feb 2024 18:17:52 -0800, Keith Thompson wrote:

> The signedness of plain char is implementation-defined.

Why? Because the PDP-11 on which C and Unix were originally developed did
sign extension when loading a byte quantity into a (word-length) register.

Signed characters make no sense.

Andreas Kempe <kempe@lysator.liu.se> writes:
> Den 2024-02-03 skrev Keith Thompson <Keith.S.Thompson+u@gmail.com>:
>> Andreas Kempe <kempe@lysator.liu.se> writes:
>>>
>>> Why not use a char in exit() instead of int, with wait() returning the
>>> full 16 bits? If the program itself fills in the upper 8 bits, it
>>> makes sense, but otherwise I don't understand from an API perspective
>>> why one would use a data type with the caveat that only half is used.
>>
>> C tends to use int values even for character data (when not an element
>> of a string). See for example the return types of getchar(), fgetc(),
>> et al, and even the type of character constants ('x' is of type int, not
>> char).
>
> I thought the reason for the int return type was to have an error code
> outside of the range of the valid data, with EOF being defined as
> being a negative integer. A reason that isn't applicable for the
> argument passing to exit by a program.

I don't think there's one definitive reason for either decision.

>> In early C, int was in many ways a kind of default type. Functions with
>> no visible declaration were assumed to return int. The signedness of
>> plain char is implementation-defined.
>
> I realised that char was a bad example just as I posted. I should have
> chosen unsigned char instead.

The exit() function predates unsigned char (see K&R1). It probably even
predates char. (C's predecessor B was untyped, with characters being
stored in words which were effectively of type int. There was an exit()
function, but it apparently took no arguments.)

Changing exit()'s parameter type to reflect the range of valid values
undoubtedly wasn't considered worth doing -- especially since a wider
range of values might be valid on some systems.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Fri, 02 Feb 2024 18:17:52 -0800, Keith Thompson wrote:
>
>> The signedness of plain char is implementation-defined.
>
> Why? Because the PDP-11 on which C and Unix were originally developed did
> sign extension when loading a byte quantity into a (word-length) register.
>
> Signed characters make no sense.

Except in architectures where they do. If you're doing something where
it matters (or even if you want your code to be more readable) used
signed char or unsigned char as appropriate.

On Sat, 03 Feb 2024 20:33:19 -0700, Joe Pfeiffer wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Fri, 02 Feb 2024 18:17:52 -0800, Keith Thompson wrote:
>>
>>> The signedness of plain char is implementation-defined.
>>
>> Why? Because the PDP-11 on which C and Unix were originally developed
>> did sign extension when loading a byte quantity into a (word-length)
>> register.
>>
>> Signed characters make no sense.
>
> Except in architectures where they do.

There are no character encodings which assign meanings to negative codes.

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Fri, 02 Feb 2024 18:17:52 -0800, Keith Thompson wrote:
>>> The signedness of plain char is implementation-defined.
>>
>> Why? Because the PDP-11 on which C and Unix were originally developed did
>> sign extension when loading a byte quantity into a (word-length) register.
>>
>> Signed characters make no sense.
>
> Except in architectures where they do.

Such as?

> If you're doing something where it matters (or even if you want your
> code to be more readable) used signed char or unsigned char as
> appropriate.

Signed 8-bit integers are perfectly sensible, signed characters not so
much.

--
https://www.greenend.org.uk/rjk/

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Sat, 03 Feb 2024 20:33:19 -0700, Joe Pfeiffer wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Fri, 02 Feb 2024 18:17:52 -0800, Keith Thompson wrote:
>>>
>>>> The signedness of plain char is implementation-defined.
>>>
>>> Why? Because the PDP-11 on which C and Unix were originally developed
>>> did sign extension when loading a byte quantity into a (word-length)
>>> register.
>>>
>>> Signed characters make no sense.
>>
>> Except in architectures where they do.
>
>There are no character encodings which assign meanings to negative codes.

But then 'signed char' doesn't necessarily need to be used
for character encoding (consider int8_t, for example, which
defines a signed arithmetic type from -128..+127.

On the 16-bit PDP-11, signed 8-bit values would not have been uncommon,
if only because of the limited address space.

Andreas Kempe <kempe@lysator.liu.se> writes:
> Den 2024-02-03 skrev Keith Thompson <Keith.S.Thompson+u@gmail.com>:
>> Andreas Kempe <kempe@lysator.liu.se> writes:

[...]

> If C was first with having an exit() function and an int return for
> main, I can imagine that it went something like this
>
> - C chooses int for main
> - C uses int in exit() to match main
> - OS folks want to store extra data in the exit status, but they
> want to match the C API
> - let's just stuff it in the upper bits and keep the API the same with
> an imposed restriction on the value in POSIX
>
> or POSIX exit() was constructed with the int from main in mind, or it
> could just be, as you point out, that int is a nice default integer
> type and there wasn't much thought put into it beyond that.
>
> I can speculate a bunch different reasons, but I'm curious if anyone
> knows what the actual reasoning was.

This should be pretty obvious: A C int is really a machine data type in
disguise, namely, whatever fits into a common general purpose register
of a certain machine. C was created for porting UNIX to
the PDP-11 (or rather, rewriting UNIX for the PDP-11 with the goal of
not having to rewrite it again for next type of machine which would need
to be supported by it). Putting a value into a certain register is a
common convention for returning values from functions (or rather, Dennis
Ritchie probably thought it would be a sensible convention at that
time). Hence, having main return an int was the 'natural' idea and
allocating the lower half of this int to applications whising to return
status codes and the upper half to the system for returning
system-specific metadata was also the 'natural' idea.

Surely, eight whole bits must be enough for everyone! :-)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[...]

> (On Plan 9, a program's exit status is (was?) a string, empty for
> success, a description of the error condition on error. It's a cool
> idea, but I can imagine it introducing some interesting problems.)

That's interesting to know as I have been using the same convention for
validation functions in Perl for some years: These return nothing when
everything was ok or a textual error message otherwise.

On Sat, 03 Feb 2024 20:33:19 -0700, Joe Pfeiffer
<pfeiffer@cs.nmsu.edu> wrote:

> Signed characters make no sense.

Nor did 6 bit characters, but in the 1980s we had them:
3 characters in a 24 bit word.
Welcome to what was then called mini or midrange computers.

(Yes, looking at you, Harris, with its Vulcan Operating System)

--
Regards,
Kees Nuyt

Thank you everyone for the different informative replies and
historical insight! I think I have gotten what I can out of this
thread.

On Mon, 05 Feb 2024 18:22:59 +0100, Kees Nuyt wrote:

> On Sat, 3 Feb 2024 21:37:55 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
> Signed characters make no sense.
>
> Nor did 6 bit characters, but in the 1980s we had them:
> 3 characters in a 24 bit word.

I see your sixbit and raise you Radix-50, which packed 3 characters into a
16-bit word.

None of these used signed character codes, by the way. So my point still
stands.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 05 Feb 2024 18:22:59 +0100, Kees Nuyt wrote:
>> On Sat, 3 Feb 2024 21:37:55 -0000 (UTC), Lawrence D'Oliveiro wrote:
>> Signed characters make no sense.
>>
>> Nor did 6 bit characters, but in the 1980s we had them:
>> 3 characters in a 24 bit word.
>
> I see your sixbit and raise you Radix-50, which packed 3 characters into a
> 16-bit word.
>
> None of these used signed character codes, by the way. So my point still
> stands.

My understanding is that on the PDP-11, making plain char signed made
code that stored character values in int objects more efficient.
Sign-extension was more efficient than zero-filling or something like
that. I don't remember the details, but I'm sure it wouldn't be
difficult to find out.

At the time, making such code a little more efficient was worth the
effort -- and character data with the high-order bit set to 1 was rare,
so it didn't make much difference in practice.

I don't know whether there are efficiency issue on modern platforms. If
modern CPUs have similar characteristics to the PDP-11, that could
impose some pressure to keep signed characters. And the representation
requirements for the character types (especially with C23 requiring
2's-complement) mean that signed characters don't cause many practical
problems.

Since C code has always had to work correctly if plain char is signed,
there wasn't much pressure to make it unsigned (though some platforms do
so).

I'd be happy if some future C standard mandated that plain char is
unsigned, just because I think it would make more sense, but I don't
think that's likely to happen. But the historical reasons for allowing
plain char to be signed are valid.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */