That's a good instinct to have. 99% of the time we're writing something like an object library that's part of a much larger program. To use global variables in such code would impose difficulties on the application as a whole, with regard to things like threading, pollution of the linker symbol table, etc. But when you're writing small main.c programs like this one which don't use threads, globals can be a real advantage. In gdb, you can easy inspect their values. You can look at the linker output manifest listing to see how they're being arranged in your binary. If you look at a lot of the old original UNIX programs that were written back in the day, a lot of them looked very similar to this. So it's a great style. It's just not one that scales to large monolithic programs that most companies prefer to create. So over the years a cultural aversion to it was developed in many style guides.
I typically split any single main.c app into two parts: a library which depends on no shared State and a driver program that wraps around it. It's a lot harder to build than a monolithic main.c but in my experience it allows more people to build off of your application.
>If you look at a lot of the old original UNIX programs that were written back in the day, a lot of them looked very similar to this. So it's a great style.
The original UNIX programs weren't known for good style or being big free
Then why is everything based on UNIX then? (Or at least fated to be, via WSL.) If you want a real jewel, check out the v6 rand() function. It's an example of a function so bad that world-class experts on the subject of randomness have been falling over themselves for decades in academic papers talking about how to fix it.
It's not based off UNIX's code. UNIX based system's popularity can essentially be attributed to network effects. For most use cases it's good enough that it's not worth switching to something better because you lose the mountain of resources (both technological and human) that exist in the UNIX ecosystem.
