It was a then-important optimization to do the most common operations with macros since calling a function for every getc()/putc() would have slowed I/O down too much.
That's why there is also fgetc()/fputc() -- they're the same as getc()/putc() but they're always defined as functions so calling them generated less code at the callsite at the expense of always requiring a function call. A classic speed-vs-space tradeoff.
But, yeah, it was a mistake that it originally used a "char" to store the file descriptor. Back then it was typical to limit processes to 20 open files ( https://github.com/dspinellis/unix-history-repo/blob/Researc... ) so a "char" I'm sure felt like plenty.
> The creator of MINIX, Andrew Tanenbaum, asked the community to choose between Stevie and Elvis to be adopted as the main text editor for their OS. Elvis was chosen and it's the default text editor on MINIX until today.
A few months ago I happened to install Debian/unstable on a G4 mini. ppc32 is no longer a supported architecture -- purely "what you get is what you get".
Still, the process was mostly painless. Everything I needed worked out of the box.
> in that case, a compiler still must set something up to fulfil the main `noexcept` promise - call `std::terminate()`
This is actually something that has been more of a problem in clang than gcc due to LLVM IR limitations... but that is being fixed (or maybe is already?) There was a presentation about it at the 2023 LLVM Developer's meeting which was recently published on their youtube channel https://www.youtube.com/watch?v=DMUeTaIe1CU
The short version (as I understand) is that you don't really need to produce any code to call std::terminate, all you need is tell the linker it needs to leave a hole in the table which maps %rip to the required unwind actions. If the unwinder doesn't know what to do, it will call std::terminate per the standard.
IR didn't have a way of expressing this "hole", though, so instead clang was forced to emit an explicit "handler" to do the std::terminate call
After seeing how term limits work in the California state legislature, I stopped being a fan of them.
The first (small) problem is that it caused unneeded intra-party drama. Effective assembly members would end up forced to seek a "promotion" into the state senate if they wanted to stay in politics. This often meant challenging members of the same party. This ends with people constantly fighting their "allies" to scramble up the greased pole, rather than doing more useful work.
Of course, that can happen even without term limits (politicians are the ambitious sort) but they definitely accelerate the effect.
The worse problem is that all of the legislators are now short-timers. But do you know who aren't newbs? The lobbyists! Since they're now the only ones around with deep experience, they invariably get even more involved with crafting laws.
This actually dove-tails into the other problem with the lobbying industry: the revolving door from legislator to the lobbying firm. Even without term limits this happens all of the time. It's very common for a retiring US House member to immediately get a lucrative job lobbying their former colleagues. However in a term-limited legislative body this only gets worse. Not only do lobbyists become more powerful, but term limits provide a guaranteed flow of politicians needing a new job.
So, if you find yourself as a newly-elected politician in such a system and you actually want to make a difference, probably your best bet is to immediately find some lobbyists to get sweet with. They are the only ones with the experience to make the political machinery work, and they're probably your future employer as well.
So at least in my observation, the ultimate effect of term-limits is to transfer power from democratically elected representatives to well-funded special interests. By un-entrenching the politicians you're accidentally making another group even more entrenched.
By contrast, I think the very top legislators are ones that become a true expert in their field of interest. Imagine somebody who has been working on, say, education policy for decades. They know every policy detail, all of the stakeholders, all of the experts. In a world of term limits, how will such a person ever emerge?
All of the above is specifically about legislative term limits. I believe the case for executive term limits is much stronger.
Probably the person you're replying to is just confused because before it was standardized some snprintf() implementations returned -1 on overflow. If you were trying to be portable and defensive you'd need to check for either error return.
Not really a concern inside musl because those implementations are probably long gone and because it's calling its own snprintf() anyway.
It remained a valuable skill into the 1990s when many UNIX machines still had a separate /usr partition.
Many times I'd have to fix a server with a configuration issue causing /usr to not mount correctly on boot. When you're at a single-user shell and no /usr/bin/vi is available suddenly knowing the basics of /bin/ed becomes very useful.
Of course these days most UNIXes moved away from a separate /usr partition so if the root filesystem mounts you have a full-featured vim.
That much is true -- the difference between 6 and 7 registers is much larger than the benefit of going from 14 to 15.
However, even under zero register pressure having a frame pointer is still an extra register that needs to be touched on every function invocation, extra instructions taking space in the I-cache, etc. It's a small thing, but it's still a cost that has to be paid by all compiled code.
I'm not going to claim that re-enabling frame pointers was the wrong choice -- the people involved in the debate know the tradeoffs and I have to start with the assumption that I would have made the same decision if I were in their position. It does make me slightly sad, though. The idea behind removing frame pointers isn't that backtraces aren't important, it's that computing the frame pointer after-the-fact is possible -- i.e. for normal functions without alloca() or dynamically-sized stack arrays map %rip -> frame size.
The problem seems to be that despite years of experience with "no-frame-pointer" being the default I guess the profiling tools never got as reliable or good as the with-frame-pointer variants. My personal hope was that the problem would fade over time as tools improved, but it seems that's unlikely to ever happen. After all, once no-frame-pointer stops being the default there won't be any pressure for tools to improve. The towel has been thrown in.
> when I had two or more files of the same size, and the size was larger than a few MB, they likely had the same content.
Yes, if the number of files is small enough, then "notice unique file sizes" is really the only optimization that ends up mattering much. If you have a few thousand files and they're each multiple gigabytes then hopefully you'll get lucky and no two will have the same size.
But the ideal tool should also try to handle the opposite case well too.
First, imagine if you have a huge collection of unique ~100KiB files. Now the "birthday paradox" means that size collisions are inevitable so optimizing the total I/O needed to prove two files are different starts to belp.
But the pathological case is even worse -- what if nearly all of your files are about the same size? For instance, suppose you have a program that is recording time-series data from a sensor and rotating the file every time it grows to 10MB. This sort of thing happens all the time dealing with scientific data sets -- you might have a directory with thousands of large files, all exactly the same size. If you want to quickly verify none of the files are dups, reading one block from each is far more efficient than hashing them all.
Don't expect it to do much, but it's fascinating if you're interested in OS history.