From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30735 invoked from network); 16 Dec 2022 16:24:02 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 16 Dec 2022 16:24:02 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 9B714423C4; Sat, 17 Dec 2022 02:23:39 +1000 (AEST) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) by minnie.tuhs.org (Postfix) with ESMTPS id B740A423C2 for ; Sat, 17 Dec 2022 02:23:34 +1000 (AEST) Received: by mail-vs1-f46.google.com with SMTP id 128so2709831vsz.12 for ; Fri, 16 Dec 2022 08:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=T38artG8tvGdvBdReokvA19nrC5fdEgg986PVY8lSFU=; b=bHjSYX+oin8AJ0Gta/Hwm3b1/HisntDJKcbi/8465Wp6XrbAao8aGM9Q/QXmmxwMus 1DmuGFL2oEc7uy/FiI+Jr2XR4TroB8ppIHVl5dQScc5eYbhgHnH2glYuiAl0igbQmEcd bEdXzvWNUyUxNR3HBKJcMG30iUlBGjC/X4BUNe85X5uUmCmzKUXlu1qtGtSXjKjNrl8E Ht5CieoIevwNwUuV+bWJF7LDzbXuiYNzRbl33Wewm9u6HOsGe0JCXII2d0T0rZmGj4Ax kn6qE59gAX+F2yDSMqpzCe9qOI98dkTt6vapKZ5EokSs9TsMfxgBaEwru6P4PzmNY8TA gofg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=T38artG8tvGdvBdReokvA19nrC5fdEgg986PVY8lSFU=; b=I6J2TRs3nJesMdv+cZaXvx1mJlPuyo9gkgMjpHQjZCBLiTxdff3Ibojql4VAZtX2dp +ZhBqEEQWCS1BH24uC7Wf2vIUdHRCKc2pE1U5FMA3X7WzU3e9sBMBWEwmr0tSh/oegIa 0A5gRhlZnTPWKHuAhd6A4lZVxbm+D0YtDJ9GcyLK8UpJclbsVikqTLUlTJG02kVOIuUj gvJrQtizjHZmgMsqdwye7gvZtKSENSX4AciJfn3ufLQ7ImxR9B/gjRpr+E04cpUaxchE XIaPRQThogyyzATMOI/P4FEwH2T4sqhEXesT+WTsmwIUp7kPxH/UajeTTZMeWdtV1Pgl Ktig== X-Gm-Message-State: ANoB5pmXK9YonCM2gOrhag+P1Oy1qqgLC/gTeopvvpULkd9s2YRXUSkB pU8UfgWUI1ithaTXliqDI3Oa/VJsvGNkZkcY3jk= X-Google-Smtp-Source: AA0mqf46OH4xNPRe5FprXDTddUmKuFYZZUclPzHlrngFrBqZCt3CduClNmpng9p+pujYQ3Af1LuUpOlrQPlfq1BsWHQ= X-Received: by 2002:a05:6102:3bd1:b0:3b1:3d51:73fd with SMTP id a17-20020a0561023bd100b003b13d5173fdmr13334230vsv.55.1671207753567; Fri, 16 Dec 2022 08:22:33 -0800 (PST) MIME-Version: 1.0 References: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> <514474eb-5ef5-9c78-0a42-73c7d82e9a65@halwitz.org> In-Reply-To: From: Tom Lyon Date: Fri, 16 Dec 2022 08:22:22 -0800 Message-ID: To: Dan Cross Content-Type: multipart/alternative; boundary="0000000000007f53b905eff460b4" Message-ID-Hash: 4ZPXBG4WLVDH7ZPJH2CZBCU43O37ZEEE X-Message-ID-Hash: 4ZPXBG4WLVDH7ZPJH2CZBCU43O37ZEEE X-MailFrom: pugs78@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: origin of null-terminated strings List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000007f53b905eff460b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Re: getting a 360 - IBM and AT&T really hated each other, so 360s were avoided for strategic reasons. That said, they could not be practically avoided; Holmdel had a large installation: https://www.youtube.com/watch?v=3DHMYiktO0D64&ab_channel=3DAT%26TTechChanne= l When Amdahl and UTS/UNIX came along, the Bell System was by far the biggest customer. On Fri, Dec 16, 2022 at 8:12 AM Dan Cross wrote: > On Fri, Dec 16, 2022 at 8:42 AM Dan Halbert wrote: > > ASCIZ was an assembler directive used for a number of different DEC > computers, and also the name for null-terminated strings. I learned it fo= r > 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. > > This raises something I've always been curious about. To what extent were > the Unix folks at Bell Labs already familiar with DEC systems before the > PDP-7? > > It strikes me that much of the published work was centered around IBM and > GE > systems (e.g., Ken's wonderful paper on regular expressions, and of cours= e > the > Multics work). Were there other Digital machines floating around? I know = a > proposal was written to get a PDP-10 for operating systems research, but = it > wasn't approved. > > Relatedly, was any thought given to trying to get a 360 system? > > On 12/16/22 04:13, Dr Iain Maoileoin wrote: > > ASCIZ > > Lost in the mists of time in my mind. > > Origin, perhaps, but it exists in contemporary assemblers. Like most > sane people I try to avoid being in assembler for too long, when you're > first turning on a machine it is useful to be able to squirt a message > out of the UART if something goes dramatically wrong, and the directive > is handy for that. > > It seems to have made its way into Research assembler via BSD; it's in > locore.s in 8th Edition, for instance, but doesn't appear before that. T= he > "UNIX Assembler Manual" describes "String Statements" for the 7th > Edition assembler; strings are sequences of ASCII characters between > '<' and '>'. But it doesn't say that they're NUL terminated, and they ar= e > not: adding the terminator was manual via the familiar, `\0` escape > sequence. > > - Dan C. > > > > I remember running into a .asciz directive n the 70s =E2=80=9Csomewhere= =E2=80=9D. > > It was an assembler directive in one of the RT11 systems??? or perhaps > the unix bootstrap and/or =E2=80=9C.s=E2=80=9D files - when I get some ti= me 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 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=E2=80=99s because th= e PDP-7 > >> microprocessor, on which UNIX and the C programming language were > >> invented, had an ASCIZ string type. ASCIZ meant =E2=80=9CASCII with a = Z (zero) > >> at the end.=E2=80=9D > >> > >> 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 > > > > > > > --0000000000007f53b905eff460b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Re: getting a 360 - IBM and AT&T really hated each oth= er, so 360s were avoided for strategic reasons. That said, they could not b= e practically avoided; Holmdel had a large installation:=C2=A0https://www.youtube.com/watch?v=3DHMYiktO0D64&ab_channel=3DAT%26TT= echChannel

When Amdahl and UTS/UNIX came along, the = Bell System was by far the biggest customer.

On Fri, Dec 16, 2022 at 8= :12 AM Dan Cross <crossd@gmail.com> wrote:
On= Fri, Dec 16, 2022 at 8:42 AM Dan Halbert <halbert@halwitz.org> wrote:
> ASCIZ was an assembler directive used for a number of different DEC co= mputers, and also the name for null-terminated strings. I learned it for th= e 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 ass= embly programming would have known about it. Various system calls took ASCI= Z strings.

This raises something I've always been curious about. To what extent we= re
the Unix folks at Bell Labs already familiar with DEC systems before the PD= P-7?

It strikes me that much of the published work was centered around IBM and G= E
systems (e.g., Ken's wonderful paper on regular expressions, and of cou= rse the
Multics work). Were there other Digital machines floating around? I know a<= br> proposal was written to get a PDP-10 for operating systems research, but it=
wasn't approved.

Relatedly, was any thought given to trying to get a 360 system?

On 12/16/22 04:13, Dr Iain Maoileoin wrote:
> ASCIZ
> Lost in the mists of time in my mind.

Origin, perhaps, but it exists in contemporary assemblers. Like most
sane people I try to avoid being in assembler for too long, when you're=
first turning on a machine it is useful to be able to squirt a message
out of the UART if something goes dramatically wrong, and the directive
is handy for that.

It seems to have made its way into Research assembler via BSD; it's in<= br> locore.s in 8th Edition, for instance, but doesn't appear before that.= =C2=A0 The
"UNIX Assembler Manual" describes "String Statements" f= or the 7th
Edition assembler; strings are sequences of ASCII characters between
'<' and '>'.=C2=A0 But it doesn't say that they&#= 39;re NUL terminated, and they are
not: adding the terminator was manual via the familiar, `\0` escape
sequence.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.


> I remember running into a .asciz directive n the 70s =E2=80=9Csomewher= e=E2=80=9D.
> It was an assembler directive in one of the RT11 systems??? or perhaps= the unix bootstrap and/or =E2=80=9C.s=E2=80=9D files - when I get some tim= e 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.
>>
>>=C2=A0 =C2=A0 =C2=A0Why do C strings [have a terminating NUl]? It= =E2=80=99s because the PDP-7
>> microprocessor, on which UNIX and the C programming language were<= br> >> invented, had an ASCIZ string type. ASCIZ meant =E2=80=9CASCII wit= h a Z (zero)
>> at the end.=E2=80=9D
>>
>> This assertion seems unlikely since neither C nor the library stri= ng
>> functions existed on the PDP-7. In fact the "terminating char= acter" of
>> a string in the PDP-7 language B was the pair '*e'. A stri= ng was a
>> sequence of words, packed two characters per word. For odd-length<= br> >> 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 f= or
>> ASCII,=C2=A0 https://dl.acm.org/doi/10.1145/363= 831.363839. There the only
>> role specifically suggested for NUL is to "serve to accomplis= h 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=C2=A0 tru= th in the
>> attribution to ASCIZ.
>>
>> Doug
>
>
>
--0000000000007f53b905eff460b4--