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=-1.0 required=5.0 tests=HTML_MESSAGE, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8579 invoked from network); 16 Dec 2022 09:14:16 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 16 Dec 2022 09:14:16 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id DBA86423B9; Fri, 16 Dec 2022 19:13:39 +1000 (AEST) Received: from newtrichead.scotnet.co.uk (newtrichead.scotnet.co.uk [217.16.223.153]) by minnie.tuhs.org (Postfix) with ESMTP id A1A0D423AC for ; Fri, 16 Dec 2022 19:13:31 +1000 (AEST) Received: from [192.168.0.161] (92.41.136.224.threembb.co.uk [92.41.136.224]) (authenticated bits=0) by newtrichead.scotnet.co.uk (8.14.7/8.14.7) with ESMTP id 2BG9DOuE026556 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2022 09:13:26 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_CB8EFA73-7A66-45AF-A188-4A3213931708" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dr Iain Maoileoin In-Reply-To: Date: Fri, 16 Dec 2022 09:13:35 +0000 Message-Id: <78A69F72-788E-4A31-B750-A39C97F77C75@csp-partnership.co.uk> References: To: Ken Thompson X-Mailer: Apple Mail (2.3124) Message-ID-Hash: WL4OJAJXSSZCDFQVXZEDB5225ULHZ3RN X-Message-ID-Hash: WL4OJAJXSSZCDFQVXZEDB5225ULHZ3RN X-MailFrom: iain@csp-partnership.co.uk 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: Douglas McIlroy , Alejandro Colomar , TUHS main list 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: --Apple-Mail=_CB8EFA73-7A66-45AF-A188-4A3213931708 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 ASCIZ Lost in the mists of time in my mind. 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 = 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 wrote: >=20 > asciz -- this is the first time i heard of it. > doug -- yes. >=20 >=20 > On Thu, Dec 15, 2022 at 7:04 PM Douglas McIlroy = > = wrote: > I think this cited quote from > https://www.joelonsoftware.com/2001/12/11/ = is urban legend. >=20 > Why 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 > invented, had an ASCIZ string type. ASCIZ meant =E2=80=9CASCII with a = Z (zero) > at the end.=E2=80=9D >=20 > 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. >=20 > 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. >=20 > Ken would probably know for sure whether there's any truth in the > attribution to ASCIZ. >=20 > Doug --Apple-Mail=_CB8EFA73-7A66-45AF-A188-4A3213931708 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 ASCIZ
Lost in the mists of time in my = mind.

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 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=E2=80=99s = because the 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

= --Apple-Mail=_CB8EFA73-7A66-45AF-A188-4A3213931708--