20 Dec
2016
20 Dec
'16
1:05 p.m.
From: Tony Finch
when did C get its cast operator?
Well after that piece of code was written! :-)
I don't recall exactly off the top of my head, but I recall 2-3 notes to
users about the evolution of C post 'vanilla' V6; I think a lot of it was
related to work being done on typetting stuff, hence the moniker
'phototypsetter compiler' which was applied to that 'improved' C.
One of the notes is fairly common, but another I have only in hardcopy
(although I scanned it at one point).
I'll try and turn all of them, along with some notes I made about the
differences between 'vanilla' V6 C and 'phototypsetter C' (which a lot
of the
later V6 users started with - I certainly did), into an article on the
Computer History wiki on the early evolution of C.
Noel
20 Dec
20 Dec
3:49 p.m.
New subject: nm on Third Edition .o files?'
On Tue, Dec 20, 2016 at 8:05 AM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
I think a lot of it was
related to work being done on typetting stuff, hence the moniker
'phototypsetter compiler' which was applied to that 'improved' C.
Need to ask someone like Doug or Steve - but I thought/IIRC the moniker
was because it was the compiler an end user got when you get the typesetter
code. That said, you have to be right in that it was the typesetter work
that seems to be the forcing function. As for dating it, it has to have
predated the "white book" because we had the typesetter compiler at CMU
before Ted Kowalski showed up for his OYOC year which I'm pretty sure was
'76.
He had brought UNIX/TS with him and a xerographic copy of the white book
proofs. We had been running 5th and then 6th edition in '75 - when I
started hacking. Ted updated us to his system and that spread everywhere
but the two CS IUS and SUS (image and speech understanding systems).
I believe that I can date this because IUS and SUS had a special CMU 11/40e
microcode (csav and cret instructions) and hacked typesetter C compiler,
which was different from what Ted was using (which was even later). So
these systems could not use Ted's new kernel until someone in CS brought
the two compilers in sync (Dan Klein maybe??) - I remember is was a pain in
the tuckus because you could not take a binary from the CS systems and run
them on the EE Dept systems. But the CS system had more disk than we did,
so they had all of the sources from outside places like MIT, UCB, et al on
line. We I was grabbing tools from those systems to update the EE systems
and pushing what we wrote back to them.
Clem
4:04 p.m.
New subject: nm on Third Edition .o files?'
If I recall, we got the typesetter (troff) tape in between V6 and the later (I think we
got PWB next then V7). It had a compiler on it. I presume that it was needed to
compile troff, but most of us installed it as a more up to date C compiler. If I recall
properly (and boy my mind is hazy on this), is that it supported the “new” += syntax while
warning that =+ was deprecated.
At some point, the structure elements being made unique to the structure they were defined
in, and the ability to assign/pass structures got supported, though I thought that was the
compiler that came with V7.
I’m still annoyed they didn’t fix arrays when they fixed structs.
4:09 p.m.
New subject: nm on Third Edition .o files?'
On Tue, Dec 20, 2016 at 11:04:13AM -0500, Ron Natalie wrote:
At some point, the structure elements being made
unique to the structure they were defined in
I, for one, would have been really OK if that had been optional.
If it is what I am thinking about, that all struct elements were in the
same namespace, forcing names like "st_size" instead of just "size",
I love that. I get that it doesn't scale but man, so nice when reading
code to know that s.st_size is a stat structure.
4:23 p.m.
New subject: nm on Third Edition .o files?'
And nothing precludes you from tagging the structure elements. We continued to do that
long after the compiler was “fixed.”
From: Clem Cole [mailto:clemc@ccc.com]
Sent: Tuesday, December 20, 2016 11:22 AM
To: Larry McVoy
Cc: Ron Natalie; Noel Chiappa; TUHS main list
Subject: Re: [TUHS] nm on Third Edition .o files?'
On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
I get that it doesn't scale but man, so nice when reading
code to know that s.st_size is a stat structure.
Amen!!!
4:26 p.m.
New subject: nm on Third Edition .o files?'
On Tue, Dec 20, 2016 at 11:23:34AM -0500, Ron Natalie wrote:
And nothing precludes you from tagging the structure
elements.
We continued to do that long after the compiler was ???fixed.???
Oh, agreed. The aware people do that. I just wish it was the default
that it enforced one namespace. For all i know gcc has this and I
haven't noticed.
8:23 p.m.
New subject: nm on Third Edition .o files?'
I had a funny and somewhat embarrassing experience around the whole
issue of structure name spaces. When types were spreading through C,
we had a lot of discussion about whether we should require all
programs to call structures with a structure pointer (which would
allow a separate name space for structure members of each
structure). We all thought it was a good idea, but the problem was
there was a lot of code out there that didn't conform, including a lot
of OS code. As we started to port Unix to the Interdata (a 32-bit
machine), the situation became critical. So I took a deep breath and
implemented the following: the compiler would use the old style
structure rules until I saw a "new style" structure reference in the
code. At that point I would start to enforce the new rules, which
involved translating the symbol table, and starting to complain if the
types didn't match. This was a very ugly hack, and I had inserted
many firewalls and assertions to check that the data structures were
correct after this translation.
Now, a word about error messages. The PDP-11 didn't have much
memory. But at the same time it didn't have much of a debugger in
those days. So the main aim was to identify what went wrong in a
small number of characters so you could put in print statements and
run it again. This meant that the message produced had to be short
but also unique. I was producing error checks at a great rate in
this code and running out of synonyms for "corrupted" in my messages.
I "published" the code, and everything seemed to be working for a
couple of days. Then Ken, who was working on the Interdata file
system, tried to compile a structure declaration that contained a
sizeof of a structure that was recursively declared inside of the
sizeof, and my code gave up the ghost. Ken came into my office with
a strange look on his face and asked "What is a gummy structure?"
----- Original Message -----
From:
"Clem Cole" <clemc(a)ccc.com>
To:
"Larry McVoy" <lm(a)mcvoy.com>
Cc:
"TUHS main list" <tuhs(a)minnie.tuhs.org>rg>, "Noel Chiappa"
<jnc(a)mercury.lcs.mit.edu>
Sent:
Tue, 20 Dec 2016 11:21:41 -0500
Subject:
Re: [TUHS] nm on Third Edition .o files?'
On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy <lm(a)mcvoy.com [1]>
wrote:
I get that it doesn't scale but man, so nice when reading
code to know that s.st_size is a stat structure.
Amen!!!
Links:
------
[1] mailto:lm@mcvoy.com
8:30 p.m.
New subject: nm on Third Edition .o files?'
touchė
On Tue, Dec 20, 2016 at 3:23 PM, Steve Johnson <scj(a)yaccman.com> wrote:
I had a funny and somewhat embarrassing experience
around the whole issue
of structure name spaces. When types were spreading through C, we had a
lot of discussion about whether we should require all programs to call
structures with a structure pointer (which would allow a separate name
space for structure members of each structure). We all thought it was a
good idea, but the problem was there was a lot of code out there that
didn't conform, including a lot of OS code. As we started to port Unix to
the Interdata (a 32-bit machine), the situation became critical. So I took
a deep breath and implemented the following: the compiler would use the old
style structure rules until I saw a "new style" structure reference in the
code. At that point I would start to enforce the new rules, which involved
translating the symbol table, and starting to complain if the types didn't
match. This was a very ugly hack, and I had inserted many firewalls and
assertions to check that the data structures were correct after this
translation.
Now, a word about error messages. The PDP-11 didn't have much memory.
But at the same time it didn't have much of a debugger in those days. So
the main aim was to identify what went wrong in a small number of
characters so you could put in print statements and run it again. This
meant that the message produced had to be short but also unique. I was
producing error checks at a great rate in this code and running out of
synonyms for "corrupted" in my messages.
I "published" the code, and everything seemed to be working for a couple
of days. Then Ken, who was working on the Interdata file system, tried to
compile a structure declaration that contained a sizeof of a structure that
was recursively declared inside of the sizeof, and my code gave up the
ghost. Ken came into my office with a strange look on his face and asked
"What is a gummy structure?"
----- Original Message -----
From:
"Clem Cole" <clemc(a)ccc.com>
To:
"Larry McVoy" <lm(a)mcvoy.com>
Cc:
"TUHS main list" <tuhs(a)minnie.tuhs.org>rg>, "Noel Chiappa" <
jnc(a)mercury.lcs.mit.edu>
Sent:
Tue, 20 Dec 2016 11:21:41 -0500
Subject:
Re: [TUHS] nm on Third Edition .o files?'
On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
I get that it doesn't scale but man, so nice
when reading
code to know that s.st_size is a stat structure.
Amen!!!
2691
days inactive
2691
days old
8 comments
5 participants
participants (5)
-
Clem Cole -
jnc＠mercury.lcs.mit.edu -
Larry McVoy -
Ron Natalie -
Steve Johnson