From: Dan Halbert <halbert@halwitz.org>
To: tuhs@tuhs.org
Subject: [TUHS] Re: origin of null-terminated strings
Date: Fri, 16 Dec 2022 08:42:12 -0500 [thread overview]
Message-ID: <514474eb-5ef5-9c78-0a42-73c7d82e9a65@halwitz.org> (raw)
In-Reply-To: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]
ASCIZ was an assembler directive used for a number of different DEC
computers, and also the name for null-terminated strings. I learned it
for the PDP-10, but I'm sure it existed on other machines. It is in some
PDP-10 documentation I am looking at right now. Anyone who used DEC and
did assembly programming would have known about it. Various system calls
took ASCIZ strings.
On 12/16/22 04:13, Dr Iain Maoileoin wrote:
> ASCIZ
> Lost in the mists of time in my mind.
>
> I remember running into a .asciz directive n the 70s “somewhere”.
> It was an assembler directive in one of the RT11 systems??? or perhaps
> the unix bootstrap and/or “.s” files - when I get some time I will go
> read some old code/manuals.
>
> I
>
> Yes, it put a null byte at the end of a string.
>
>> On 16 Dec 2022, at 03:14, Ken Thompson <kenbob@gmail.com> wrote:
>>
>> asciz -- this is the first time i heard of it.
>> doug -- yes.
>>
>>
>> On Thu, Dec 15, 2022 at 7:04 PM Douglas McIlroy
>> <douglas.mcilroy@dartmouth.edu> wrote:
>>
>> I think this cited quote from
>> https://www.joelonsoftware.com/2001/12/11/ is urban legend.
>>
>> Why do C strings [have a terminating NUl]? It’s because the PDP-7
>> microprocessor, on which UNIX and the C programming language were
>> invented, had an ASCIZ string type. ASCIZ meant “ASCII with a Z
>> (zero)
>> at the end.”
>>
>> This assertion seems unlikely since neither C nor the library string
>> functions existed on the PDP-7. In fact the "terminating
>> character" of
>> a string in the PDP-7 language B was the pair '*e'. A string was a
>> sequence of words, packed two characters per word. For odd-length
>> strings half of the final one-character word was effectively
>> NUL-padded as described below.
>>
>> One might trace null termination to the original (1965) proposal for
>> ASCII, https://dl.acm.org/doi/10.1145/363831.363839. There the only
>> role specifically suggested for NUL is to "serve to accomplish time
>> fill or media fill." With character-addressable hardware (not the
>> PDP-7), it is only a small step from using NUL as terminal padding to
>> the convention of null termination in all cases.
>>
>> Ken would probably know for sure whether there's any truth in the
>> attribution to ASCIZ.
>>
>> Doug
>>
>
[-- Attachment #2: Type: text/html, Size: 5515 bytes --]
next prev parent reply other threads:[~2022-12-16 13:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 3:02 [TUHS] " Douglas McIlroy
2022-12-16 3:14 ` [TUHS] " Ken Thompson
2022-12-16 9:13 ` Dr Iain Maoileoin
2022-12-16 13:42 ` Dan Halbert [this message]
2022-12-16 16:10 ` Dan Cross
2022-12-16 16:22 ` Tom Lyon
2022-12-16 16:29 ` Jon Steinhart
2022-12-16 20:12 ` Dave Horsfall
2022-12-16 21:02 ` Warner Losh
2022-12-16 21:13 ` Clem Cole
2022-12-16 21:49 ` Clem Cole
2022-12-17 0:26 ` Phil Budne
2022-12-16 21:18 ` Luther Johnson
2022-12-16 21:20 ` Dan Halbert
2022-12-16 3:17 ` Steve Nickolas
2022-12-16 17:24 ` John P. Linderman
[not found] ` <6009124d-750d-365e-a424-ec7bb25922b9@gmail.com>
2022-12-16 22:30 ` [TUHS] Terms for string, and similar character constructs (was: origin of null-terminated strings) Alejandro Colomar
2022-12-16 22:51 ` [TUHS] " Dave Horsfall
2022-12-16 22:26 [TUHS] Re: origin of null-terminated strings Douglas McIlroy
2022-12-17 2:03 ` James Frew
2022-12-17 3:42 ` steve jenkin
2022-12-17 17:11 ` Clem Cole
2022-12-17 18:15 ` Tom Lyon
2022-12-17 18:43 ` Clem Cole
2022-12-17 18:46 ` Clem Cole
2022-12-17 19:26 ` Tom Perrine
2022-12-19 4:26 ` Adam Thornton
2022-12-16 23:11 Noel Chiappa
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=514474eb-5ef5-9c78-0a42-73c7d82e9a65@halwitz.org \
--to=halbert@halwitz.org \
--cc=tuhs@tuhs.org \
/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).