Garance A Drosihn wrote:
> >The point about
> >
> > (void)fclose(pfp);
> > if (ferror(pfp)) {
> > ...do stuff...
> > }
> >
> >is that it's a silly thing to do deliberately, but if I was
> >porting some hairy old C code I'd tend to expect it to work.
> >C is not a language in which you go out of your way to prevent
> >people making mistakes.
>
> I would not expect it to work. This has nothing to do with
> the C language, it has to do with fclose. Fclose gets rid
> of the descriptor. In my own code, I usually follow 'fclose(fp)'
> with 'fp = NULL', because that stream is GONE. I do realize that
> this code does seem to work on several operating systems, but it
> also causes dramatic problems with linux. Given the description
> of fclose, I'd say it is the code which is wrong.
This has to do with the C language at least in the sense that the
standard library is a part of C. About half the bulk of the original
ANSI/ISO C Standard is taken up with specifying the library.
I don't think I really disagree with the points you make, mostly
not quoted; but I also think the fundamental issue is that you're
not entirely in sympathy with the C way of doing things, and that
you'd prefer to be using something else. (Someone who does the
fp = NULL thing is quite likely deep-down a Modula-3 guy, or an
Oberon guy, or an Ada guy, or something. :-)
The _Rationale_, which was put out by the original ANSI committee
somewhat in defence of the C Standard itself, talks about sticking
to "the spirit of C". And the first of the tenets it mentions is
"Trust the programmer".
It's probably fair to say that the lack of sanity-checking in the
routines of the standard library is one example of that kind of
trust. Though whether it is sensible to trust the programmer not
to make silly mistakes is a different matter altogether, of course.
--
Robert Nordier
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
