Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!rutgers!njin!princeton!cs!cs.Princeton.EDU!nfs
From: nfs@cs.Princeton.EDU (Norbert Schlenker)
Newsgroups: comp.os.minix
Subject: Re: Misfeature in fclose.c
Summary: Not really
Message-ID: <1526@rossignol.Princeton.EDU>
Date: 31 Jul 90 15:04:25 GMT
References: <19575@orstcs.CS.ORST.EDU>
Sender: news@cs.Princeton.EDU
Organization: Dept. of Computer Science, Princeton University
Lines: 30

In article <19575@orstcs.CS.ORST.EDU> regan@jacobs.CS.ORST.EDU (Dave Regan) writes:
>It appears that there is a deficiency in fclose when called with a
>NULL parameter (which isn't good practice anyway).

Calling fclose with a NULL parameter is an error.

>ANSI says that fclose needs to return EOF if the stream was previously
>closed.

Not true - the standard says no such thing.

>The code can be easily extended to protect itself if called
>with a NULL parameter.  If this protection is not in place, at the very
>least "free" is called with NULL and some other arbitrary value. This
>isn't good.
>
><additional justification and patch deleted>

But this is a programming error.  If you want to saddle the library with
all manner of checks, you are free to do so.  Most programmers do not want
the additional overhead to be incurred.  The stdio package that I posted
long ago included error checking as an option - needless to say, I don't
use it myself.  I expect programs not to call fclose() with a NULL pointer,
just as I expect programs not to call strcpy() with NULL pointers.

Programs which call standard library routines with arguments that are not
of the expected form may fail.  That has always been the case, and ANSI
has now codified it.  Programmers beware!

Norbert