8 Nov
2017
8 Nov
'17
4:07 p.m.
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.
N.
8 Nov
8 Nov
4:12 p.m.
New subject: 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:
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
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.
7:59 p.m.
New subject: origins of void* -- Apology!
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
8:28 p.m.
New subject: NUXI Problem
On Wed, Nov 08, 2017 at 11:07:10AM -0500, Nemo wrote:
What was that story about porting an early UNIX to a
machine with
different char polarity? I dimly recall only a few problems.
The NUXI problem on the Interdata 7/32, when the University of Wollongong
did the port of Sixth Edition.
I can't find a link to the actual story, but from memory the system
printed "NUXI" out when it was first booted.
Cheers, Warren
8:38 p.m.
New subject: NUXI Problem
I seem to recall the story was an early IBM Series 1 port. Seemed to
recall them relating that at a UNIX Users Group meeting.
-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Warren Toomey
Sent: Wednesday, November 8, 2017 3:29 PM
To: Nemo
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] NUXI Problem
On Wed, Nov 08, 2017 at 11:07:10AM -0500, Nemo wrote:
What was that story about porting an early UNIX to a
machine with
different char polarity? I dimly recall only a few problems.
The NUXI problem on the Interdata 7/32, when the University of Wollongong
did the port of Sixth Edition.
I can't find a link to the actual story, but from memory the system printed
"NUXI" out when it was first booted.
Cheers, Warren
8:39 p.m.
New subject: NUXI Problem
Close it, was the Series/1 port not the Interdata.
It was reported at the 1980 USENIX by the folks from Cleveland State that
ported it. The Series/1 was not byte-swapped.
Clem
On Wed, Nov 8, 2017 at 8:28 PM, Warren Toomey <wkt(a)tuhs.org> wrote:
On Wed, Nov 08, 2017 at 11:07:10AM -0500, Nemo wrote:
What was that story about porting an early UNIX
to a machine with
different char polarity? I dimly recall only a few problems.
The NUXI problem on the Interdata 7/32, when the University of Wollongong
did the port of Sixth Edition.
I can't find a link to the actual story, but from memory the system
printed "NUXI" out when it was first booted.
Cheers, Warren
11:14 p.m.
New subject: NUXI Problem
On Thu, Nov 09, 2017 at 06:28:33AM +1000, Warren Toomey wrote:
On Wed, Nov 08, 2017 at 11:07:10AM -0500, Nemo wrote:
Oops, I stand corrected (by private e-mails), it was the IBM Series/1.
I'll blame bit rot, or perhaps the Interdata also suffered from the NUXI
problem.
Thanks, Warren
What was that story about porting an early UNIX to
a machine with
different char polarity? I dimly recall only a few problems.
The NUXI problem on the Interdata 7/32, when the University of Wollongong
did the port of Sixth Edition. 
11:33 p.m.
New subject: origins of void* -- Apology!
Warner Losh <imp(a)bsdimp.com> wrote:
|On Wed, Nov 8, 2017 at 9:07 AM, Nemo <[1]cym224(a)gmail.com[/1]> wrote:
|On 6 November 2017 at 19:36, Ron Natalie <[2]ron(a)ronnatalie.com[/2]> 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 \
..
|When I was working on FreeBSD/arm only a decade ago, I'd routinely \
|hit both of these issues...
I had one of those on Debian/arm64 (Bug#806300) no sooner but
November 2015, very friendly reported as
|This symptom and the pattern of failures is typical of programs that
|assume that plain char is signed. Fortunately there's a warning in
|the build log that tells you exactly where the bug is:
(in fact already mentioned in some hidden archlinux forum, and
also to me in private by a Swede, but i failed to see, and forgot,
hu-hu!!, all in March 2015) introduced in December 2013 when
blindly fixing CC warnings (Many: fix gcc 4.8.2 -fstrict-overflow
-Wstrict-overflow=5). Testing char not int against EOF is bad.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
9 Nov
9 Nov
1:35 a.m.
New subject: origins of void* -- Apology!
I don't think either Dennis or I ever thought that characters should
be signed. It's true that PCC didn't specify it. It's also true
that in those days the 8th bit in a char was pretty much unused
(except by the shell), so the issue never arose. I believe the folks
at Bell Labs Holmdel who did the port to the Vax were the first ones
to come up with signed characters. I think it was a real blot on
C. For example, consider:
struct { ....
char x:1;
...
}
If characters are signed, the only legal values of x are 0 and -1 (!)
Steve
----- Original Message -----
From:
"Warner Losh" <imp(a)bsdimp.com>
To:
"Nemo" <cym224(a)gmail.com>
Cc:
"The Eunuchs Hysterical Society" <tuhs(a)tuhs.org>
Sent:
Wed, 8 Nov 2017 09:12:50 -0700
Subject:
Re: [TUHS] origins of void* -- Apology!
On Wed, Nov 8, 2017 at 9:07 AM, Nemo <cym224(a)gmail.com [1]>
wrote:
On 6 November 2017 at 19:36, Ron Natalie <ron(a)ronnatalie.com [2]>
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
Links:
------
[1] mailto:cym224@gmail.com
[2] mailto:ron@ronnatalie.com
2363
days inactive
2364
days old
8 comments
7 participants
participants (7)
-
Clem Cole -
Nemo -
Ron Natalie -
Steffen Nurpmeso -
Steve Johnson -
Warner Losh -
Warren Toomey