Re: [9fans] GUI toolkit for Plan 9

[presotto@plan9.bell-labs.com]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

I think 3B2 code deserves its own place in hell.  Poring over
the ESS#5 code, someone found that there were lots of
strcmp(p, "f(") == 0 checks (I may have gotten the exact
string wrong but it's close).  It took us a while to figure
out why.  Apparently, location 0 on the 3b had the 3 bytes
'f' '(' '\0', someone noticed that when programs blew up
they were pointing to "f(", and the worlds most amazing
kludge for detecting nil pointers was born.

I'm beginning to be convinced that, with the exception
of Ken's registerization, bugs in optimizing compilers
are more likely mistakes than knowing attempts to hang
over the edge too far.

I heard a rumor yesterday that I'ld like dispelled if
possible.  It was that the Linux kernel had to be compiled
with optimization turned on to work.  I just tried compiling
my Redhat system without and it crashed but then I
turned optimization on and it still didn't work, so clearly
I'm incompetent.

[-- Attachment #2: Type: message/rfc822, Size: 2887 bytes --]

From: "AMSRL-CI-CN" <gwyn@arl.army.mil>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Thu, 28 Feb 2002 14:55:33 GMT
Message-ID: <Gs8z4H.Hwp@arl.army.mil>

<presotto@plan9.bell-labs.com> wrote in message
news:181b9e858518e43368953c1050365780@plan9.bell-labs.com...
> what works and what doesn't.  Moving from the VAX to the
> 68020 uncovered lots of null references that were going
> unnoticed in the past.

Long ago, I went through all the user-mode UNIX System V
source code and identified and fixed as many of these kinds
of bugs as I could find.  Unfortunately the system for trouble
reporting was utterly not up to the task of feeding these back
to the official developers.  I think finally most of them got fixed
indirectly via Sun picking them up when Guy Harris helped
merge the System V and BSD sources for them, since he had
my fixed-up System V sources to work from.

Anyway, in the process of doing that work, also in dealing
with some of the code from the AT&T UNIX System
ToolChest, I found that a lot of these VAXisms appeared to
have turned up when AT&T moved the code to 3B2s
(WE32000 architecture), but instead of changing the code to
be truly portable, workarounds were installed under control
of #ifdef u3b conditionals.  Maybe that resulted from some
policy of having to overdocument every change to the base
code unless it was made processor-specific; I don't know.

The biggest culprits seemed to be passing 0 to terminate
execl argument lists and dereferencing argv[i] before testing
for i==argc.