[TUHS] nm on Third Edition .o files?

Diomidis Spinellis dds at aueb.gr
Tue Dec 20 06:49:20 AEST 2016

Thank you so much for the explanation.  I was aware that in old C 
structures a->b references were interpreted as *(a + b), but didn't know 
that early C was so close to B that it could run most B programs by just 
adding some declarations.  It seems a logical evolutionary and 
bootstrapping step.

What I'm trying to do is study the dependencies between the kernel's 
files.  Maybe a good approximation would be to consider all functions as 
global and ignore variables.

On 19/12/2016 22:33, Steve Johnson wrote:
> That's a construction that's left over from B.  The number on the left
> is a PDP-11 address, probably for some kind of control register.
> In B, all data was stored in the same sized bucket.  For arrays, the
> bucket contained the address of the beginning of the storage allocated
> for the array.  For data, the bucket contained the data.  On a
> byte-addressed machine, Dennis had to do some real magic to load and
> execute these programs (e.g., shift addresses right by a bit).  And, of
> course, because there were no types, there was no type checking, and
> thus no way to disambiguate structure members, so all names of structure
> members had to be unique.  If one structure had a member "next", no
> other structure could have a member "next".   (actually, it could if
> they were at the same offset in the two structures, but that was pretty
> dangerous...).  And early C (originally called nb, "new B") had to be
> able to run most B programs by just adding some declarations...
> I can't help you with nm, but it might not tell you much if you had it...
> Steve
>     ----- Original Message -----
>     From:
>     "Diomidis Spinellis" <dds at aueb.gr>
>     To:
>     "TUHS main list" <tuhs at minnie.tuhs.org>
>     Cc:
>     Sent:
>     Mon, 19 Dec 2016 21:47:28 +0200
>     Subject:
>     [TUHS] nm on Third Edition .o files?
>     . . .
>     However, I stumbled on the use of structure fields on things that
>     aren't
>     structures, e.g. "0177776->int =| 300"

More information about the TUHS mailing list