The “story” was the reticence to require something that MIGHT take additional
instructions. Again, this stems from yet another overload of char, that of a small
numeric type (many languages do not treat characters as integers). The idea was to let
char be the regular char type and if you were going to do math on it, you’d better
explicitly state signed/unsigned, of course, people get sloppy leading to the bugs you
noted.
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Warner Losh
Sent: Wednesday, November 8, 2017 11:13 AM
To: Nemo
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] origins of void* -- Apology!
On Wed, Nov 8, 2017 at 9:07 AM, Nemo <cym224(a)gmail.com> wrote:
On 6 November 2017 at 19:36, Ron Natalie <ron(a)ronnatalie.com> wrote:
It’s worse than that. “char” is defined as neither
signed nor unsigned.
The signedness is implementation defined. This was why we have the inane
“signed” keyword.
What was that story about porting an early UNIX to a machine with
different char polarity? I dimly recall only a few problems.
Doesn't even have to be very early... There's lots of 'assume char is
signed bugs' in even modern code. So many that ARM gave up on the idea that unsigned
char was good (since the underlying ARM architecture supported it better) and their modern
ABIs are all signed char. The other thing that EABI fixes is the crazy alignment rules
that were out-of-step with the rest of the computer industry that broke a lot of
networking and storage code on ARM because its rules caused structs that would otherwise
describe the binary layout to be suddenly wrong. Yes, that is an implementation choice,
just a poor one that was eventually corrected.
When I was working on FreeBSD/arm only a decade ago, I'd routinely hit both of these
issues...
Warner