Re: fclose() again

From: Marc Lehmann (pcg@goof.com)
Date: Sat Jul 15 2000 - 12:08:50 EST


> I think the library might need to be patched, wherever it is segfaulting.

The current c9x standard 8actually, the last draft) says this:

       [#2] The fclose function causes the stream pointed to by
       stream to be flushed and the associated file to be closed.
       Any unwritten buffered data for the stream are delivered to
       the host environment to be written to the file; any unread
       buffered data are discarded. The stream is disassociated
       from the file. If the associated buffer was automatically
       allocated, it is deallocated.

Everything else (including passing in anthing that is not a stream) causes
undefined behaviour, in our case segfaults (most of the time).

As a sidenote, neither manpages nor the libc documentation define how
C works, the ISO C standard does, and POSIX, X/Open & friends add more
functionality.

Interestingly, unix/98 says this:

The fclose() function will fail if:

EBADF]
        The file descriptor underlying stream is not valid.

Which is not the case in any examples so far (so the linux manpage is
confusing when it says "stream" instead of "file descriptor").

One could argue that the "solaris standard" says that "in 99% of the
cases, EBADF is returned, otherwise we just segfault" and the GNU standard
says "if you pass anything else in, it's undefined behaviour".

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:22 EST