In yesterday's entry, I talked about how Unix's errno is so limitedpartly because of how the early Unix kernels didn't return multiplevalues from system calls . It's worthnoting that this isn't a limitation in operating system kernels andtypical system call interfaces; instead, it's a limitation imposedby C. If anything, it's natural to return multiple values fromsystem calls.

Typically, system call interfaces use CPU registers because it'smuch easier (and usually

If you read manual pages, such as Linux's errno(3) , you'llsoon discover an important and peculiar seeming limitation oflooking at errno. To quote the Linux version:

The value in errno is significant only when the return value of thecall indicated an error (i.e., -1 from most system calls; -1 or NULLfrom most library functions); a function that succeeds is allowed tochange errno. The value of errno is never set to zero by any system

Recently I read Apps shouldn’t let users enter OpenSSL cipher-suitestrings by Frank Denis( via ), whichadvocates for providing at most a high level interface to peoplethat lets them express intentions like 'forward secrecy is required'or 'I have to comply with FIPS 140-3'. As a system administrator,I've certainly been guilty of not keeping OpenSSL cipher suitestrings up to date, so I have a good deal of sympathies for thegeneral view of trusting the clients and

One of the reactions I saw to my entry on malloc(0) being allowedto return NULL is to wonder why you'dever do a zero-size allocation in the first place. Unfortunately,it's relatively easy to stumble into this situation with simplecode in certain sorts of not particularly uncommon situations. Themost obvious one is if you're allocating memory for a variable sizeobject, such as a Python tuple or a JSON array. In a simple Cimplementation these will typically have a fixed

In an aside in a recent entry , Isaid that one reason that X terminals faded away is that what Icalled the "personal computer" model of computing had some pragmaticadvantages over the "terminal" model. One of them is that broadly,the personal computer model scales better, even though sometimesit may be more expensive or less capable at any given point in time.But first, let me define my terms. What I mean by the "personalcomputer" model is one where computing resources are distributed

Broadly, there have been three approaches to command history inUnix shells. In the beginning there was none, which was certainlysimple but which led people to be unhappy. Then csh gave us in-memorycommand history, which could be recalled and edited with shellbuiltins like '!!' but which lasted only as long as that shellprocess did. Finally, people started putting 'readline style'interactive command editing into shells, which included some historyof past commands that you could get back with cursor-up

Recently on the Fediverse I posted a puzzle about a little shellscript :

A silly little Unix shell thing that I've vaguely wanted for ages butonly put together today. See if you can guess what it's for:

#!/bin/sh
trap 'exec $SHELL' 2
"$@"
exec $SHELL

(The use of this is pretty obscure and is due to my eccentric Xenvironment.)

The actual version I now use wound up slightly more complicated,and I call it '

Suppose, not hypothetically , that you havea central CUPS print server, and that people also have Linux desktopsor laptops that they point at your print server to print to yourprinters. As of at least Ubunut 24.04, if you're doing this youprobably want to get people to turn off and disable cups-browsed on their machines.If you don't, your central print server may see a constant floodof connections from client machines running cups-browsed. You'reprobably

In a conversation on the Fediverse, I had some feelings on tapesversus disks :

I wish tape drives and tape robots were cheaper. At work economicsmade us switch to backups on HDDs, and apart from other issues itquietly bugs me that every one of them bundles in a complex read-writemechanism on top of the (magnetic) storage that's what we really want.

(But those complex read/write mechanisms are remarkably inexpensivedue to massive volume, while the corresponding tape drive+robotread/