I don't agree with you at all that 'it sucks'. I think it makes perfect sense and works as intended.
Plus, we're talking about POSIX here. You don't have a time machine. Shall we argue about just how much POSIX software is out there, working perfectly fine with this technique?
Sure, in New Fangled Language De Jour™, return as many tuples as your heart desires.
It sucks because people miss error codes, or they overwrite them, or misunderstand what they mean. You read the blog post right? That’s what I’m talking about. I deal with that all the time (maybe more than the average person, to be fair, but still it’s a lot).
I don’t really blame the people in 1970 for coming up with this design but it’s 2025 now; we can agree that it has problems. Tape recorders were also a neat idea but I can record a thousand times more on my phone now, often at higher quality. By modern standards, they suck.
>It sucks because people miss error codes, or they overwrite them, or misunderstand what they mean.
"Pointers suck", for the same reason.
In any case, its the 21st century - if you're shipping C code that hasn't been statically analyzed with 100% code coverage, you're doing it wrong.
Besides which, this is an abstraction which, once done properly once, in a library or framework, can be ignored at higher levels of abstraction, or even language runtime/execution environments, with some degree of comfort ..
> Plus, we're talking about POSIX here. You don't have a time machine. Shall we argue about just how much POSIX software is out there, working perfectly fine with this technique?
I'd argue this is in spite of choosing a path that makes maintainable software more difficult than it needs to be. Constraints change over time, and the thought process that made this practice rational no longer coheres with modern-day constraints. Maintaining software is now (much, much) more expensive than the performance minutae that led to this cost.
> Sure, in New Fangled Language De Jour™, return as many tuples as your heart desires.
This isn't related to language at all—C may not have tuples, but structs are an equivalent.
Open up your Ruby or Python or whatever, stick a breakpoint on a lower C function dependency that properly handles errno, and watch the error propagate into your languages runtime/execution context.
Problem? Nope.
errno handling has been long since adopted as a best practice, industry-wide, and the only ones who are going to get toasty fingers on this issue are newbs, or those grey beards who still think code coverage and static analysis are new-fangled tools of the trade.
So I'd argue that this problem is a straw man, the OP is just trying to find something edgy to whine about, and that actually - really the issue is that programmers just don't like to read docs, don't like to comply or conform with long-since settled standards, and are too heavily inflicted in this day and age with neurotic violations of the DRY rule to actually check themselves (or errno) before they wreck themselves (or their i/o thread) ...
