Hacker News Reader

Comment by musicale | Hacker News Reader

It's disappointing that most of the computers I use are running an OS that lacks several highly beneficial features because they would have taken up too much memory on a PDP-7 in 1970.

Consider: a kernel and userspace written in a more memory-safe language (Multics was written in PL/I and had essentially zero buffer overflows); ring security; long/human-readable command names in addition to terse abbreviations; multiple entry points for programs; etc..

View on HN

Given the hardware used for JOVIAL in 1958, or Burroughs B5000 with ESPOL/NEWP in 1961, making C safer would have been doable.

Even if not, by the time we reached 1980, with the pleothara from PL/I dialects, BLISS, Modula-2, Mesa, Object Pascal,..., it was more than possible to fix C.

Or 50 years later, where WG14 keeps ignoring the issue related to bounds checking aware types and fat pointers.

Slightly related is C language using null terminated strings which is the source of buffer overflows. From what I remember the assembly languages of whatever platform they were using relied on NUL, an alternative was to use a leading single byte to set the length of the string, so "hello_world" which is 11 bytes would be:

0x0A h e l l o _ w o r l d

But that limited the length of strings to 255 characters and using two bytes rather than one would add memory pressure. Dennis Ritchie then went with null terminated strings which has the advantage of allowing any size of strings and is consistent with the assembly they were used with. The drawbacks is decades of buffer overflows :)

Eventually I found an abstract on https://en.wikipedia.org/wiki/Null-terminated_string#History and there is a 2011 paper about it: Communications of the ACM - Volume 54 - Issue 901 - September 2011 - pp 42–44 - https://doi.org/10.1145/1995376.1995391 . Direct link to the PDF https://dl.acm.org/doi/pdf/10.1145/1995376.1995391

Safer systems programming languages relied on character arrays for lengths greather than 255, as a kind of good enough compromise, since most use cases could fit in 255, and with the help of string libraries it wasn't much of a pain to deal with character arrays instead of strings.

Eventually fat pointers were used instead.

Which even Denis himself proposed for WG14 during the C89 standardization, and wasn't accepted.

https://www.bell-labs.com/usr/dmr/www/vararray.pdf

Goes to show how being easy to understand and change is important for a project's success

They didn't take too much memory, they mostly were just a bad ideas. "Ring security" doesn't really do anything; long command names are unwieldy and counterproductive (see PowerShell) etc; memory-safe languages have always been there in UNIX.

And it's not like C can't be memory-safe, as shown by CHERI/Morello (shameless plug). It depends on hardware.

> long command names are unwieldy and counterproductive (see PowerShell)

Going to have to disagree here. PowerShell reminds me of Lisp Machines/Emacs in this regard. As long as the shell supports completions this isn't an issue and aids in habituation and discover-ability IMHO.

devils advocate: command completion is bloat. discoverability papers over poor documentation. All of this enforces the bad habit of expecting the software to hold your hand everywhere.

I like PowerShell conceptually - basically, manipulating structured objects instead of unstructured text - but the commands themselves always feel overly verbose/awkward. Maybe it's just me.

Reply on news.ycombinator.com