Kind of off topic, but why in the world in 2026 do POSIX utilities still rely on global variables to pass around state? Is it too complicated to pass around a struct address in C or something?
I think there is a class of programs where globals are not so terrible. In particular, one-shot programs that do a task and then exit (like `ls`, `cp`, etc).
You may also notice that some of these utilities will allocate memory, then never free it. They just let the OS handle that on program shutdown. That is also generally not recommended in arbitrary code. But again, it's fine for a one-and-done sort of program.
For these cases, the whole program is essentially one function call, and the global namespace is essentially the "body" of that function (hand waving a bit).
Reminds me of the story of the memory leak in a missile guidance computer. It was determined that in the worst case scenario not enough memory could leak fast enough for it to be a problem between missile launch and impact. So they just let the explosion handle the garbage collection
It really doesn't make any difference if the source for a utility exhibits terrible coding practices. If it passes the tests, then the OS can be certified.
We'd prefer Rust versions with great forethought, but it's irrelevant to the testing.
There is no current version of Linux [uswrland] that maintains certified POSIX compliance. Only Apple, IBM, HP, and SCO are current?
Because there's nothing inherently wrong with global variables. In small utilities like these, I would argue it would be less readable to do as you describe.
Sure, in anything larger, or anything that needs to be reentrant, global variables are going to hurt. But this is not that.
Because why not? "Globals bad"? goto is still being used where it makes sense as well.
It's a good rule of thumb to avoid them both, especially when you're inexperienced yet, but they still have their uses - as implied by it being a "rule of thumb".
Many of those utilities, if you inspect the source code, are recognizably the same programs as their original versions written 30+ years ago. They’ve been maintained and changed over the years, sure, but they’ve rarely needed big changes. After all, they’re simple programs that do basically the same job today as they did then, using basically the same API surface.
The main issue with this is that the programs are usually still single-threaded. For some key utilities like find and grep, this has allowed more modern alternatives to leapfrog them in performance. (To be fair, it’s hard to add parallelism without breaking compatibility somewhat.)
But in most other respects, there’s nothing wrong with being a little old-fashioned. Using global variables is an example of that. It’s a problem in larger programs but at this scale it’s fine.
dataflow · · focus · HN ↗
turtledragonfly · · focus · HN ↗
You may also notice that some of these utilities will allocate memory, then never free it. They just let the OS handle that on program shutdown. That is also generally not recommended in arbitrary code. But again, it's fine for a one-and-done sort of program.
For these cases, the whole program is essentially one function call, and the global namespace is essentially the "body" of that function (hand waving a bit).
It's all a bit subjective, of course (:
Bjartr · · focus · HN ↗
chasil · · focus · HN ↗
We'd prefer Rust versions with great forethought, but it's irrelevant to the testing.
There is no current version of Linux [uswrland] that maintains certified POSIX compliance. Only Apple, IBM, HP, and SCO are current?
<a href="https://www.opengroup.org/openbrand/register/" rel="nofollow">https://www.opengroup.org/openbrand/register/
kelnos · · focus · HN ↗
Sure, in anything larger, or anything that needs to be reentrant, global variables are going to hurt. But this is not that.
seba_dos1 · · focus · HN ↗
It's a good rule of thumb to avoid them both, especially when you're inexperienced yet, but they still have their uses - as implied by it being a "rule of thumb".
comex · · focus · HN ↗
The main issue with this is that the programs are usually still single-threaded. For some key utilities like find and grep, this has allowed more modern alternatives to leapfrog them in performance. (To be fair, it’s hard to add parallelism without breaking compatibility somewhat.)
But in most other respects, there’s nothing wrong with being a little old-fashioned. Using global variables is an example of that. It’s a problem in larger programs but at this scale it’s fine.