Marcus Ranum’s blog “stderr” is not to be parsed “st- derrrrrrrr” like the sound of a hard drive platter engaging and spinning up in response to a data request.
It’s to be parsed “std err”, as in “standard error”. Clearly my very minor experience coding was not enough.
Or your experience in statistics, where standard error is also a term of art.
Although, if it makes you feel any better, I didn’t recognize it either, and I love statistics.
For some reason I was reading it as Sergeant Derr. Clearly the name of a fictional sergeant who’s bumbling mishaps would arouse questions in the eyes of his superiors, who would then cock their heads to one side and say, “Derr?”
I have the opposite problem–whenever people talk about sexually transmitted diseases I only think about standard deviations.
There was a student in University who kept pronouncing
charas “car”, confusing everybody most of the time (even those who knew of that idiosyncrasy).Good thing it’s not named “malloc”.
This old C coder spotted it immediately. (More about what it means “below the fold” for those who care.)
blf @3: I usually pronounce it just like it’s spelled (like in “char-broiled”). Lots of folks pronounce it like “care”. I can’t remember hearing “car”.
Intransitive @4: I must be missing a joke here. I can think of only one meaning for “malloc”. Maybe I should get out more. 😎
—————————————————————————-
Once a C program is loaded, and before the code that you actually wrote starts to run, there are three files that are opened and ready to use: stdin, the standard input device (usually your keyboard), stdout, the standard output device (usually your computer’s screen), and stderr, the standard error device (usually also the screen). Back when I started, they were probably assigned to an ASR-33 Teletype. 😎 Any of the three can be redirected to files on your hard drive.
<aside>
Now that I’m using lots of C++, “std” comes up in lots of other contexts as well. I usually pronounce it as “stud”; and most of the folks I know on the ISO standards committee for C++ do, too.
</aside>
I know the tech-standard meaning, yet in online-Ranumistan, still always see it mentally as “Saint Derr”.
billseymour, it’s not the programming language, it’s the OS.
John Morales @7: Huh? If your point is that “stderr”, etc., are not keywords in the language, then, yeah; but I never said that. They’re identifiers that name pointers to a structure of type FILE that get passed to several standard library functions that perform I/O; and they’re specified in ISO/IEC 9899, the international standard for C. (I hope Crip Dyke approves of my going all legal on you. 😎 )
But we’re getting away from the point in the OP, which was a bit of fun about the pronunciation of (as I would say it) STUD-air.
#7 I’m with billseymour here. As someone who wasted a significant portion of my professional life on standards committees I can assure y’all that although the concept of the three standard streams relies on the OS, the name by which you access the stream from within a program is defined by the language, not the OS. In ANSI C stdin, stdout and stderr are defined in the header file stdio.h.
Other languages have other conventions – if you want to go way back, early Pascal had only “input” and “output”, which would have left Marcus stranded.
Well, yes, if one looks at the label, not the thing.
Point being, those ‘streams’ are not unique to C, as one might naively infer from #5.
cafebabe, Pascal had ‘input’, ‘output’, and ‘errout’, and they were ‘files’.
heh.
Another one here who initially read it as “Saint Derr”, and although I shortly figured it was likely an abbreviation for something like “standard error”, I kinda like “Saint Derr”
apologies Ranum…
billseymour (#5) –
“malloc” means memory allocation. But the English prefix “mal-” might make newbies think “bad location”.
30 years of SAS programming: char is “car”, for character data type.
I’ve to be careful of context for STD because in the same day I’ve had it have all the aforementioned meanings. Part of why English can be so fun, and infuriating.
billseymour@5, I myself am “
char-broiled”, and I have heard “care” every now and then, but it was the sheer unusualness of “car” which threw everyone (albeit I gather from @13 there may be subspecialities where that pronunciation is perhaps more common?).─────────────────────────
Also, freestanding C runtime environment does not need to provide any I/O objects or operations at all. (And the minimum requirements for a freestanding runtime is defined by both modern ISO C and its predecessor, ANSI C.) There need not be a
stdin(nor the defining<stdio.h>), etc., nor the “stream” behind it. Small-scale embedded systems developers, and also O/S developers, as two examples, routinely code for such an environment.John Morales@#7:
it’s not the programming language, it’s the OS.
It’s a convention in the C runtime. The file descriptors are set up using dup(2) on a file descriptor attached to /dev/tty before main is invoked. That code, I know well, and it’s C. The OS involvement is at the pseudodevice – note that the /dev/tty file descriptor is set up when a program is spawned with fork(2) and exec(2) – different shells, which are also generally C code, handle that differently – e.g: the Bourne Shell’s redirect 2&1 semantic which avoids the dup(2)
You shouldn’t try correcting people when you are absolutely wrong, it’s a bad look.
I consider stderr to be unpronounceable but it usually came out as “stud urr”
I love the idea of a Saint Derr. I also love the idea of a Sergeant Derr, and it’s hard to pick between the two. However for a while I knew it was really “standard error”. That’s because when Marcus first became a blogger PZ posted a video interview with several new bloggers, one of them being Marcus, and I heard him clearly say “standard error”. Nevertheless I do wish to read of the adventures of Saint Derr, which would be amazing. Maybe he miraculously cured an F-35 from being a complete piece of flying garbage!!! I would love to read that story!
@15, If you are speaking about *ix systems (such as Linux),
/dev/ttyis (usually) set up by the firstopenof a terminal device in a new session leader process. It is (typically) thendup‘ed as appropriate to create all three streams associated with the threestd…C names. Those open streams are then inherited (usually) by child (fork) processes and executed programs (exec). All this is (normally) done early on by the process which ultimately becomes, through a series ofexec‘s, the initial (“login”) shell.No shell, and neither
forknorexec, are involved in setting-up/dev/ttyin the normal course of operation.Also, the Bourne-ish shells’s
2>&1syntax is adupof some form, making stream 2 (stderr) a duplicate of the current stream 1 (stdout).blf@#18:
Also, the Bourne-ish shells’s 2>&1 syntax is a dup of some form, making stream 2 (stderr) a duplicate of the current stream 1 (stdout).
Actually, it just changed the global int. The original Bourne shell code was really horrible; he used the macro processor to sort of define a meta-language that rendered down to C. It was some of the worst abuse of cpp ever and the story I recall was that David Korn wrote ksh out of disgust. The current /bin/sh is usually “Bourne again shell” (bash) or a link to it but that is very distro centric.
I actually have source for Ultrix (4.2BSD) somewhere; I dont think it has the Original Bourne glarp. In fact I may have V7 in my archives too. I’ll check!
Marcus:
I don’t deliberately. Evidently, I was too terse and didn’t put it well, but the thing is all the file access is done by the OS. I clarified @10 — the main point intended to be that it’s not something that’s C specific, other than the label.
(Obviously, if I don’t know I’m absolutely wrong, I can’t try to do that, to clarify my first sentence)
—
On topic, I took your blog name as a self-deprecating reference to the error file.
(Noticeably, ‘stdout’ is reminiscent of ‘standout’, so different connotations)
@19, Apropos of nothing much, I do know where my archive is, albeit it’s neither easily accessible physically (it’s on a different continent) or computationally (I don’t have a 9-track 1600bpi reel-to-reel tape drive available). I do know it contains V6, V7, System III, and at least two versions of System V (and that’s just the AT&T / BTL sources); plus others. What it does not have is Plan 9.
Yeah, Bournegol (I think that’s how it was spelled) was a abuse of the preprocessor, and made both the original Bourne
shand also PDP-11adbunreadable. My memory of Dr Korn (my archive also has the originally-releasedksh) is he wanted to modify the shell, but found Bournegol impenetrable(? distracting? unmodifiable?), hence the rewrite. As *ix was ported to different processors, parts of Bourne’s shell (the memory management in particular, as I now recall) had to rewritten, I never saw a rewrite in Bournegol. I was unaware that in Bourne’s original,2>&1was just an internal assignment; that could not have lasted, since later versions executed “exec 2>&1; exec >&-correctly (meaning fdesc 2 could still be used); as far as I can recall now,n>&-really didclosefdesc n even in the early (all-Bournegol PDP-11) Bourne shell, albeit I could be recalling a slightly-later version.I couldn’t say in if in most(?) distros
/bin/shis GNU bash; in what I (usually) run, it isdash; another Bourne-ish shell (from memory, it claims to be strictly-POSIX conforming with no extensions). When I see a script starting#!/bin/shwhich contains non-POSIX constructs (usuallybash-isms), the author is in for a bolloxing. My advice is, if you think (or intend) your script is runnable by/bin/shto actually TEST it withdashas the “least common denominator” (dash script), plus whichever one (or both) of your actual/bin/shandbashis notdash.@blf: I have given up on UNIX since systemd. I’m just glad I won’t need it again, though I have an old Dell laptop with OpenBSD 3.1 that runs great. I finally realized UNIX is a kludge and I shouldn’t complain that it’s getting kludgier.
While I’ve been assuming it was short for ‘standard error’, I do mentally pronounce it as ‘st-derrrr’, although it had not occurred to me to compare it to the sound of a hard drive booting.
@22, A kludge? Yeah, I can see that, especially since the constellation of *ix systems have evolved and diversified over a (relatively speaking) very long time. It’s a kludge in a similar way, and perhaps for rather similar reasons, that the human body is a kludge.
@24 blf –
It’s worth reading Leslie Lamport’s The Future of Computing: Logic or Biology on the subject: I sincerely hope the future is logic:
https://stuff.mit.edu/afs/sipb/project/reading-group/past-readings/2009-05-19-future-of-computing.pdf
mailliw@25, Thanks for the reference ! (As an aside, is that Leslie Lamport of LaTeX fame? — another evolution-like kludge (in my definition, see below), albeit built on a solid logic-base; and like *ix, still very widely used.)
In that article, Lamport says:
Yes there are ! (Seriously.) Or, at least, were. In a sense. A few years before that article was written, an in-house “miscellaneous topics” discussion group was plagued by a group of individuals who “believed” in “crystals”. And made all sorts of outlandish claims. One eejit claimed that by adding the proper magic crystals to a car’s gas tank something good (increased mileage, as I now recall) would happen.
One hilarious thing about that was the kook’s claims were thoroughly demolished by a good friend of mine, a motorhead (car, and also aeroplane, fanatic) who, much to the kook’s embarrassment, was a woman. That shouldn’t matter, of course, and it seems telling the kook implied it did. (Apologies if you’re read this story before, this isn’t the first time I’ve mentioned it.)
After a first read of that article, my initial impression (which may change) is Dr Lamport and I mean somewhat different things with “evolving code”. I think of it as “keep what works and change what doesn’t”, with no requirement for the “change” not to “break” (other) existing code. (Other considerations might intervene.) My impression is Dr Lamport, well, I can’t work out what he thinks “evolving code” means (after one quick read!), going on about “superstition” and somehow evading “logic”. Not in my definition — Understanding what works and what doesn’t, what to keep and what to change / break, is a logic-driven process.
The result may not be simple (which certainly is not good as Dr Lamport notes), and those “other considerations” often short-out the logic-based process causing logic-evading results which perhaps can indeed be called “superstition”. It should be noted the keep / change view does not preclude deciding the system-as-a-whole needs changing / breaking, but the introduction of “superstition” may — probably does — preclude breaking.
Riffing off one of Dr Lamport’s analogies, replacing horse-drawn with petrol engined was a break; everything changed. However, neither is great, and another change — break — is needed (logic) but “superstition” is blocking and leading to Global Heating. I would call both that previous change, and the forthcoming change(s), evolutionary — which doesn’t seem to be what Dr Lamport means.
blf @26. Yes he is the LaTeX Lamport, though his main interest nowadays is formal specification.
Lamport points out that a computer program is a mathematical expression, but very few programmers think in those terms. I don’t have a background in mathematics but this way of thinking immediately made sense to me – and one of the reasons that nowadays I try to avoid “low level” methods like iteration, sequence and assignment.
As Edsgar Dijkstra observes in The Humble Programmer “I now suggest that we confine ourselves to the design and implementation of intellectually manageable programs.”
I think Lamport’s paper is in this spirit. Once we start to build systems that aren’t intellectually manageable then their behaviour becomes inscrutable – and this leads to superstitious thinking.
There is a regretable tendency to excessive complexity in computer science. In my own field of data management we can witness the disaster of SQL – a programming language designed by people who didn’t understand the relational model properly, routinely violates basic principles of the model and whose standard runs to over 2000 pages. Given that Codd’s innovation radically simplified the representation and manipulation of data and placed it on a sound mathematical basis defined by set theory and predicate logic- the definition of a relational language shouldn’t run to more than 20 pages of Backus-Naur diagrams.
I’ve always pronounced it ‘STD? Er,…’
mailliw@27, Ah, so there is a reason I’ve never been able to make sense of SQL !
Seriously, it’s on my shortlist of some of the most seriously baffling verbose gibberish I’ve had to ever work with (fortunately, not work with much).
On the BNF example: I hear you. One job I had was to rewrite (very much a “change” by “breaking”) a disaster of a compiler for an IDL (Interface Definition Language); in this case, broadly, from a C-like syntax into strictly-conforming functional C. Not quite impossible, but among other problems it meant pinning down wibbly-wobbly definitions (which was, in this case, essentially also the semantics). And wibbly-wobbly syntax, which proved to be much harder. I eventually had to produce about a dozen pages of railway-diagram syntactic diagrams to pin down that squirming monster — and perhaps the point here is I (deliberately) choose railway-diagrams (generated in LaTeX, as an aside) because otherwise “the management” wouldn’t understand (an example, perhaps, of the “other considerations” hinted-at previously).
One flaw was there was no auto-generation from the LaTeX railway input / diagrams into tests. Similarly from the definitions / semantics into tests. So the Test Suite (a radical idea, given that the original mess had none) was largely hand-coded. Amusingly, and perhaps not surprisingly, the Test Suite found mistakes in the “core” the compiler-generated code relied on.
blf @29
I think that is far too harsh. I work with SQL every working day. Although there is much wrong with it, it is still better than the alternatives for data representation and data manipulation. The trouble is that the majority of people who work with SQL (including some “experts”) don’t understand the elegant and simple theory that it was (far too loosely) based on – they don’t even understand why the relational model is called relational. Whatever its faults, SQL is a declarative rather than procedural language and thus points the way to the future. Many programmers find it hard to make that jump, but all it takes is a bit of practice – and abandoning machine level structures like loops and sequence.
The supposed “innovations” of XML, JSON and the numerous NoSQL DBMSs are a huge step backwards to the progamming intensive inflexiblity of the hierarchical DBMSs of the 1960s and 70s. All of these DBMSs were swept away by SQL DBMSs and with good reason.
The first time I saw XML my first reaction was – why does anyone want to use something that looks just like a COBOL file description?