Re: Is this a bug in libc6?
Hi,
>>"Miquel" == Miquel van Smoorenburg <miquels@cistron.nl> writes:
Miquel> In article
Miquel> <[🔎] Pine.LNX.3.96.980410234938.389A-100000@Wakko.ualberta.ca>,
Miquel> Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> wrote:
>> fclose(fp);
>> fclose(fp);
>> This is not valid. fclose's behavoir on a null fp is apparently
>> not defined, but exiting with error would be prefered to faulting.
I have looked at the standards to shed some liight on this
subject, and I failt to see any statements that a second flose is
cause for undefined behaviour, asuming you meant the technical term
``undefined'' when you say "not defined".
ANSI X3.159-1989:
______________________________________________________________________
4.9.5.1 The flcose function
Synopsis
#include <stdio.h>
int fclose (FILE *Stream)
Description
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.
Returns
The flcose function returns zero if the stream was
successfully closed, or EOF if any errors were detected.
----------------------------------------------------------------------
1.6 Definitions of terms
o Undefined Behaviour -- behaviour, upon the use of a nonportable or
erroneous program construct, of erroneous data, or of inderminately
valued objects, for which the standard imposes no
requirements. Permissible undefined behaviour ranges from ignoring
the situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
charecteristic of the environment (with or without the issuance of a
diagnostic message), to terminating a translation or execution (with
the issuance of a diagnostic message).
If a "shall" or "shall not" requirements that appears outside
of a constraint is violated, the behaviour is undefined. Undefined
behaviour is otherwise indicated in this standard by the words
"undefined behaviour" or by the omission of any explicit definition
of behavior. There is no difference in emphasis among these three;
they all describe "behaviour that is undefined."
o Unspecified behaviour -- behaviour, for a correct program construct
and correct data, for which the standard explicitly imposes no
requirements.
______________________________________________________________________
ISO/IEC 9945-1:1996
ANSI/IEEE std 1003.1; 1996 edition
POSIX:
______________________________________________________________________
8.2.3.2
The flcose function shall perform a close() on the file descriptor
that is associated with the FILE stream. It shall also mark for update
the st_ctime and st_mtime fields of the underlying file, if the stream
was writable, and if buffered data has not been written to the file
yet.
The underlying functions are write() and close().
______________________________________________________________________
I am getting too bored to type in the POSIX definition of
close, but, suffice it to say that one should not call close mutiple
times on the same file descriptor.
So technically, calling fclose twice is undefined behaviour,
since the *Streams area has an inderminate value (it definitel no
longer points to a valid stream connected to a file); and also since
the standard omits any mention of the effect of calling it twice.
Miquel> It isn't a NULL fp. It's a fp that just points to a random
Miquel> FILE * in freed up memory.
>> A double fclose is just as bad as a double free() and is not a
>> library error should it fault or corrupt memory.
Hola! Corupting memory is not acceptable behaviour! (Unless
you document this)
_____________________________________________________________________
4.10.3.2
The free function causes the space pointed to by the argument to be
deallocated, that is, made available for further allocation. If the
argument is a null pointer, no action occurs. Otherwise, if the
pointer argument does not match a poniter earlier returned by the
calloc, malloc, or realloc function, or if the space has been
deallocated by a call to free or realloc, the behaviour is undefined.
______________________________________________________________________
That is why I prefer to do:
------------------------------------------------------------
free(ptr);
ptr = 0;
----------------------------------------------------------------------
(similarily for fclose).
manoj
--
"The question is rather: if we ever succeed in making a mind 'of nuts
and bolts', how will we know we have succeeded? Fergal Toomey "It
will tell us." Barry Kort
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: