undefined

points

[-]

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).

It's all a bit subjective, of course (:

by Bjartr3 hours ago|

parent|

[-]

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

by kelnos1 hours ago|

prev|

[-]

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.

by chasil1 hours ago|

prev|

[-]

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?

https://www.opengroup.org/openbrand/register/