The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] speaking of early C compilers
Date: Mon, 27 Oct 2014 10:48:33 -0400 (EDT)	[thread overview]
Message-ID: <20141027144833.536A618C0A5@mercury.lcs.mit.edu> (raw)

    > From: Jason Stevens

    > has anyone ever tried to compile any of the old C compilers with a
    > 'modern' C compiler?
    > ...
    > How did any of this compile? How did this stuff run without clobbering
    > each-other?

As Ron Natalie said, the early kernels are absolutely littered with all sorts
of stuff that, by today's standards, are totally unacceptable. Using a
variable declared as an int as a pointer, using a variable declared as a
'foo' pointer as a 'bar' pointer, yadda-yadda.

I ran (tripped, actually :-) across several of these while trying to get my
pipe-splicing code to work. (I used Version 6 since i) I am _totally_
familiar with it, and ii) it's what I had running.)

For example, I tried to be all nice and modern and declared my pointer
variables to be the correct type. The problem is that Unix generated unique
ID's to sleep on with code like "sleep(p+1, PPIPE)", and the value generated
by "p+1" depends on what type "p" is declared as - and if you look in pipe.c,
you'll see it's often declared as an int pointer. So when _I_ wrote
"sleep((p + 1), PPIPE)", with "p" declared as a "stuct file pointer", I got
the wrong number.

I can only speculate as to why they wrote code like this. I think part of it
is, as Brantley Coile points out, historical artifacts due to the evolution
of C from (originally) BCPL. That may have gotten them used to writing code
in a certain way - I don't know. I also expect the modern mindset (of being
really strict about types, and formal about coverting data from one to
another) was still evolving back then - partly because they often didn't
_have_ the tools (e.g. casts) to do it right. Another possibility is that
they were using line editors, and maintaining more extensive source is a pain
with an editor like that. Why write "struct file *p" wnen you can just write
"*p"? And of course everyone was so space-concious back then, with those tiny
disks (an RK05 pack is, after all, only 2.5MB - only slightly larger than a
3.5" floppy!) every byte counted.


I have to say, though, that it's really kind of jarring to read this stuff.

I have so much respect for their overall structure (the way the kernel is
broken down into sub-systems, and the sub-systems into routines), how they
managed to get a very powerful (by anyone's standards, even today's) OS into
such a small amount of code... And the _logic_ of any given routine is
usually quite nice, too: clear and efficient. And I love their commenting
style - no cluttering up the code with comments unless there's something that
really needs elucidation, just a short header to say, at a high level, what
the routine does (and sometimes how and why).

So when I see these funky declarations (e.g. "int *p" for something that's
_only_ going to be used to point to a "struct file"), I just cringe - even
though I sort of understand (see above) why it's like that. It's probably the
thing I would most change, if I could.

	Noel



             reply	other threads:[~2014-10-27 14:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-27 14:48 Noel Chiappa [this message]
2014-10-27 15:09 ` Ronald Natalie
2014-10-27 15:13 ` Dave Horsfall
2014-10-27 16:52 ` Dan Cross
  -- strict thread matches above, loose matches on Subject: below --
2014-10-28  1:55 Jason Stevens
2014-10-28 12:52 ` Ronald Natalie
2014-10-27 18:16 Nelson H. F. Beebe
2014-10-27 16:50 Norman Wilson
2014-10-27 15:48 Noel Chiappa
2014-10-27 16:25 ` Dave Horsfall
2014-10-28  0:16   ` John Cowan
2014-10-27 13:54 Jason Stevens
2014-10-27 13:46 Noel Chiappa
2014-10-27 10:32 Jason Stevens
2014-10-27 13:03 ` Brantley Coile
2014-10-27 13:34   ` Ronald Natalie
2014-10-27 13:40     ` random832
2014-10-27 14:04       ` Clem Cole
2014-10-27 15:04       ` Dave Horsfall
2014-10-27 17:09 ` scj
2014-10-27 20:35   ` Ronald Natalie
2014-10-27 21:34     ` Clem Cole
2014-10-28  1:09       ` Dave Horsfall
2014-10-28  2:06         ` Clem Cole
2014-10-28 12:22           ` Ronald Natalie
2014-10-28 12:42             ` Clem Cole
2014-10-28 13:03               ` Ronald Natalie
2014-10-28 22:02                 ` John Cowan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141027144833.536A618C0A5@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).