TUHS

tuhs@tuhs.org

29 participants
6557 discussions

by Douglas McIlroy

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

2 years, 8 months

Re: origin of null-terminated strings

by jnc＠mercury.lcs.mit.edu

> From: Bob Supnik > The PDP11 had .ASCIZ, starting with Macro11 in 1972. I was just about to report on my results, after a tiny bit of digging, which included this. The important datum is that PAL-11 (in DEC-11-GGPB-D, "paper tape software", April 1970, revised March 1971), which _preceded_ Macro-11, _does not_ include .ASCIZ (although it has .ASCII). My oldest Macro-11 book (DEC-11-OMACA-B-D, "BATCH-11/DOS-11 Assembler (MACRO-11)", April 1972, revised March 1973) does have .ASCIZ. So in the DEC PDP-11 universe, it dates from sometime between 1970 and 1972. I'm not sure if Bell had any of the DEC paper tape software: "In early 1970 we proposed acquisition of a PDP-11, which had just been introduced by Digital. ... an order for a PDP-11 was placed in May. The processor arrived at the end of the summer, but the PDP-11 was so new a product that no disk was available until December. In the meantime, a rudimentary, core-only version of Unix was written using a cross-assembler on the PDP-7." So the .ASCIZ in Macro-11 wasn't until a couple of years later. Noel

2 years, 8 months

Terms for string, and similar character constructs (was: origin of null-terminated strings)

by Alejandro Colomar

[Resend from my subscribed address, as the list is subscribers-only, it seems] In C, most syscalls and libc functions use strings, that is, zero or more non-NUL characters followed by a NUL. However, there are a few cases where other incompatible character constructs are used. A few examples: - utmpx(5): Some of its fields use fixed-width char arrays which contain a sequence of non-NUL characters, and padding of NULs to fill the rest (although some systems only require a NUL to delimit the padding, which can then contain garbage). - Some programs use just a pointer and a length to determine sequences of characters. No NULs involved. - abstract sockets: On Linux, abstract Unix socket names are stored in a fixed-width array, and all bytes are meaningful (up to the specified size), even if they are NULs. Only special that that the first byte is NUL. Since those are only rare cases, those constructs don't seem to have a name; some programmers call them strings (quite confusingly). Has there been any de-facto standard (or informal naming) to call those things, and differentiate them? Thanks, Alex -- <http://www.alejandro-colomar.es/>

2 years, 8 months

Please reinstate

by Aaron

I accidentally unsubscribed Sent from my iPhone

2 years, 8 months

Continued celebration of Warren's Flame

by Will Senn

All, I recently migrated my blog - it's new and improved, of course:) over to https://decuser.github.io. When I saw Warren was awarded Usenix's "The Flame" last week, I thought it appropriate that one of my first new blog posts celebrate Warren and his well deserved award. Here's the post: https://decuser.github.io/unix/2022/12/15/usenix-flame-award-2022.html Thanks again to Warren, both for the initiative, and for the maintenance of one of my all time favorite archives. Thanks, Will

2 years, 8 months

UNIXabilia

by James Frew

Having recently emeritated, I'm clearing out my university office and giving away hundreds of books. It occurs to me that some of them may be of interest to some of the folks on this list. (Before you ask, no, you can't have my original printed-on-Kleenex versions of the Lions notes...) Most of the books are listed here: https://www.librarything.com/catalog/james.frew . They're (alas) utterly uncategorized, but include a fair amount of UNIX, C, and general CS stuff. I also have some manuals and USENIX conference proceedings even LibraryThing couldn't locate; they're listed in the attached Markdown file. None of these proceedings are online at usenix.org, so I'd be stoked if someone volunteered to scan them. If you want any of them, let me know, and we'll figure out some way to reimburse me for shipping them. (No charge for the "content".) Or if you're close enough to Santa Barbara, come and get 'em. Cheers, /Frew <https://purl.org/frew>

2 years, 8 months

Re: Clever code

by Rudi Blom

I vaguely remember having read here about 'clever code' which took into account the time a magnetic drum needed to rotate in order to optimise access. Similarly I can imagine that with resource restraints you sometimes need to be clever in order to get your program to fit. Of course, any such cleverness needs extra documentation. I only ever programmed in user space but even then without lots of comment in my code I may already start wondering what I did after only a few months past. Cheers, uncle rubl -- The more I learn the better I understand I know nothing.

2 years, 8 months

OT - Remington Rand ad from 1956

by Rich Morin

This is rather off-topic, but some folks here might find it amusing... A Univac Commercial from Remington Randt - 1956 https://www.youtube.com/watch?v=-Ge0N080qw8& -r

2 years, 8 months

Re: Clever code [ really PB 250 ]

by Jon Steinhart

Wow, this brings back memories. When I was a kid I remember visiting a guy who had a barn full of computers in or around Princeton, N.J. There was a Burroughs 500, a PB 250, and a PDP-8. The 500 was a vacuum tube and nixie display machine. That sucker used a lot of neon, and I seem to remember that it used about $100 worth of electricity in 1960s dollars just to warm it up. I think that the PB 250 was one of the first machines built using transistors. I assume that all of you know what a PDP-8 is. I remember using the PDP-8 using SNAP (simple numeric arithmetic processor) to crank out my math homework. Note that the PB 250 also had SNAP, but in that case it was their assembler. Some of the first serious programming that I did was later at BTL on 516-TSS using FSNAP (floating-point SNAP) written by Heinz. Maybe he can fill us in on whether it was derived from SNAP. Anyway, I could only visit the place occasionally because it was far from home. Does anyone else out there know anything about it? It's a vague memory brought back by the mention of the 250. Jon

2 years, 8 months

Re: Clever code

by jnc＠mercury.lcs.mit.edu

> From: Stuff Received > I had always thought of a delay line as a precursor to a register (or > stack) for storing intermediate results. Is this not an accurate way of > thinking about it? No, not at all. First: delay lines were a memory _technology_ (one that was inherently serial, not random-access). They preceded all others. Second: registers used to have two aspects - one now gone (and maybe the second too). The first was that the _technology_ used to implement them (latches built out of tubes, then transistors) was faster than main memory - a distinction now mostly gone, especially since caches blur the speed distinction between today's main memory and registers. The second was that registers, being smaller in numbers, could be named with a few bits, allowing them to be named with a small share of the bits in an instruction. (This one still remains, although instructions are now so long it's probably less important.) Some delay-line machines had two different delay line sizes (since size is equivalent to average access time) - what one might consider 'registers' were kept in the small ones, for fast access at all times, whereas main memory used the longer ones. Noel

2 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS