Re: open(2) vs fopen(3)

[Linus Torvalds <torvalds@osdl.org>]

On Thu, 14 Sep 2006, Junio C Hamano wrote:
>
> Another issue related with this is that stdio implementations
> tend to have unintuitive interaction with signals, one fine
> example of it being the problem we fixed with commit fb7a653,
> where on Solaris fgets(3) did not restart the underlying read(2)
> upon SIGALRM.

Yeah. However, I think it's worth just posting the code in question to 
explain _why_ error handling with stdio sucks so badly, and why nobody 
does it..

Here's the snippet:

                if (!fgets(line, sizeof(line), stdin)) {
                        if (feof(stdin))
                                break;
                        if (!ferror(stdin))
                                die("fgets returned NULL, not EOF, not error!");
                        if (errno != EINTR)
                                die("fgets: %s", strerror(errno));
                        clearerr(stdin);

so with the <stdio.h> functions, you have to check FOUR DIFFERENT THINGS 
(1: return value, 2: feof() value, 3: ferror() value, and 4: errno) to get 
things right, and to add insult to injury, you then have to do an explicit 
clear.

In other words, the fundamental reason nobody bothers checking errors with 
stdio is that stdio just makes it a damn pain in the ass to do so - by 
having a million different thing you have to do (and ordering actually 
matters).

In contrast, the <unistd.h> interfaces are a paragon of clarity: you check 
just two things - the return value, and possibly "errno".

Now, <unistd.h> isn't perfect either, and in the kernel we have simplified 
things further, by getting rid of "errno", and just having the return 
value contain errno too. Making things not only trivially thread-safe, but 
also actually easier to code and understand, because you don't have 
anything to be confused about: the return value is always the only thing 
you need to look at in order to know what went wrong.

But unistd.h sure is a lot better than stdio in this area. Of course, 
stdio.h is just a lot easier to use when you don't actually care about the 
errors, which is also partly the _reason_ why caring about errors is so 
hard (the whole separate clearerr() and ferror() interfaces exist exactly 
_because_ people don't care about errors in many cases, and you're 
supposed to maybe have some way to test at the end whether an error 
happened or not).

So stdio.h is pretty much geared towards delayed error handling, which in 
practice ends up often meaning "no error handling at all".

			Linus