The format of strings in early (pre-C) Unix
The very earliest version of Unix was written before C was created and even after C's creation the whole system wasn't rewritten in it immediately. Courtesy of the Unix Heritage Society, much of the surviving source code from this era is available online. It doesn't make up a complete source tree for any of the early Research Unixes, but it does let us peek back in time to read code and documentation that was written in that pre-C era.
In light of a recent entry on C strings, I became curious about what
the format of strings was in Unix back before C existed. Even in
the pre-C era, the kernel and assembly language programs needed
strings for some things; for example, system calls like
open() have to take filaname arguments in some form, and
programs often have constant strings for messages that they'll print
out. So I went and looked at early Unix source and documentation,
for Research V1 (entirely pre-C), Research V2, and Research V3.
I will skip to the punchline:
Unix strings have been null-terminated from the very beginning of Unix, even before C existed.
Unix did not get null-terminated strings from C. Instead, C got null-terminated strings from Unix (specifically, Research V1 Unix). I don't know where V1 Unix got them from, if anywhere.
creat creates a new file or prepares to rewrite an existing file called name; name is the address of a null--terminated string. [...]
The V1 shell also contains uses of null-terminated strings. These are written with an interesting notation:
[...] bec 1f / branch if no error jsr r5,error / error in file name <Input not found\n\0>; .even sys exit [...] qchdir: <chdir\0> glogin: <login\0> [...]
Not all strings in the shell are null-terminated in this way,
probably because it was natural to have their lengths just known
in the code. If we need more confirmation, the
specifically comments that a
0 byte is the end of the 'line' (here
error: movb (r5)+,och / pick up diagnostic character beq 1f / 0 is end of line mov $1,r0 / set for tty output sys write; och; 1 / print it br error / continue to get characters 1: [... goes on ...]
I suspect that one reason this format for strings was adopted was
simply that it was easy to express and support in the assembler.
Based on the usage here, a string was simply a '
that supported some escape sequences, including
\0 for a null
byte; presumably this was basically copied straight into the object
file after escape translation. There's no need for either the
assembler or the programmer to count up the string length and then
get that too into the object code somehow.
(It turns out that the V1
documents all of this.)
PS: it's interesting that although the V1
write system call
supports writing many bytes at once, the
error code here simply
does brute force one character at a time output. Presumably that
was just simpler to code.
Update: See the comments for interesting additional information and pointers. Other people have added a bunch of good stuff.