From owner-cvs-all  Mon Sep 28 17:34:24 1998
Return-Path: <owner-cvs-all>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id RAA04561
          for cvs-all-outgoing; Mon, 28 Sep 1998 17:34:24 -0700 (PDT)
          (envelope-from owner-cvs-all)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA04471;
          Mon, 28 Sep 1998 17:33:51 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id KAA22366;
	Tue, 29 Sep 1998 10:33:30 +1000
Date: Tue, 29 Sep 1998 10:33:30 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199809290033.KAA22366@godzilla.zeta.org.au>
To: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, eivind@FreeBSD.ORG
Subject: Re: cvs commit: src/lib/libc/stdio fclose.3
Sender: owner-cvs-all@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>  Modified files:
>    lib/libc/stdio       fclose.3 
>  Log:
>  Document that we will core-dump on getting a NULL pointer.
                                                null (no way we can get NULL)

This goes without saying.  We may do anything on getting an invalid
pointer (i.e., an arg that isn't a pointer to an open stream, in
particular a null pointer).

>  Revision  Changes    Path
>  1.2       +4 -0      src/lib/libc/stdio/fclose.3

+1 -6 to add $Id$ and delete the section on returning EBADF might be
correct.  The documentation could say something like "EBADF  The named
stream is not actually a stream, but appears to be the carcass of a
stream that was fclosed.  This behaviour is an implementation detail,
so it should not be depended on.  Why am I documenting this?"

Bruce