I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
This is interesting. It shows that (apparently) early on, assembler was
viewed as the primary programming language.
It also shows the consequences a small, apparently local decision can have:
here we are 40+ years later and GCC on Windows is still preprending
underscores to function names!
In 15 minutes I helped the guy at work solve a problem he'd been working
on for two days!
> From: Brantley Coile <brantley(a)coraid.com>
> To: Dave Horsfall <dave(a)horsfall.org>
> Date: Mon, 20 Feb 2012 18:34:26 -0600
> Cc: The Eunuchs Hysterical Society <tuhs(a)tuhs.org>
> Subject: Re: [TUHS] why the leading under score added to function names?
> correct. we could link to assembler code with _entry points and not
i> worry about symbol collisions in the rest of the code.
> iPhone email
> On Feb 20, 2012, at 6:23 PM, "Dave Horsfall" <dave(a)horsfall.org> wrote:
> > On Mon, 20 Feb 2012, arnold(a)skeeve.com wrote:
> > [...]
> >> I'm pretty sure this dates back to PDP-11 days. I'm wondering "why?".
> >> Why did the C compiler prepend an underscore to function names?
> > Sure was the PDP-11 :-) I vaguely recall that it was to make sure that
> > user functions did not conflict with predefined assembler functions, as
> > that would be a pain to diagnose (much like having swap overlap root).
> > -- Dave
Recently at work I helped someone figure out that when working with ld,
the name of a function "foo" gets turned into "_foo" by the compiler.
(It took this old-timer 15 minutes to solve a problem he had been working
on for two days!)
I'm pretty sure this dates back to PDP-11 days. I'm wondering "why?".
Why did the C compiler prepend an underscore to function names?
All, I've just received from Poul-Henning Kamp a document entitled
"UNIX Program Description", dated January 1976 and written by the
UNIX Support Group. It contains detailed descriptions of the functions
inside a Unix kernel. Given the date and the USG origin, I'm guessing
that the system described is PWB/1.0. Can anybody confirm this at all?
The URL is http://minnie.tuhs.org/Archive/PDP-11/Distributions/usdl/unix_program_descr…
but I'll move it if it turns out not to be about PWB.
I love how new documents and artifacts keep appearing! Thanks phk.
If I recall well the /sbin directory first appeared in HP/UX,
and the name stood for 'Static binaries'. Its reason for existence
was that with the introduction of shared libraries the file with
the C-library had become a single point of failure. Therefore this
sbin was introduced to hold Statically linked executables for the
most important commands needed to fix a broken system (sh, ls, mv,
cp, find, tar, fsck etcetera). With this directory earlier than
/bin in his PATH the administrator could at least restore a working
libc.so file. And, while we are at it, the name 'executable' was
not commonly used: they were called 'binaries' (except in IBM
mainframe terminology were they were called 'load modules').
Only much later the habit of /sbin = System binaries emerged.
An important reason to split /bin vs. /usr/bin and /lib vs. /usr/lib
etc. was that the root file system had to be kept small. The fsck
program, while at work, builds tables. If possible, they stay in
memory, but if memory runs out fsck writes them to disk. However,
you don't want them to be written to an untrusted/unchecked file
system, and certainly not to the file system currently under repair.
Since the root file system has to be checked before the others, it
had to be small enough so ensure that fsck could run memory-based
only. Therefore: the /bin, /lib and other root-fs based directories
held the minimal stuff needed for booting and for repairs/restores,
while all the rest had to go into the "overflow" directories /usr/bin,
/usr/lib etc (and, obviously, /usr was a separately mounted partition).
Remember: those were the days that every reboot included a full
fsck on all your partitions.
Hendrik-Jan Thomassen <hjt(a)ATComputing.nl>
6546 BE Nijmegen NL Fax +31 24 352 72 92
'If you think education is expensive, then try ignorance.'