[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <06b24cbe-8610-31e5-f80f-4ab69bae5595@redhat.com>
Date: Thu, 24 Sep 2020 10:14:48 -0400
From: Carlos O'Donell <carlos@...hat.com>
To: libc-coord@...ts.openwall.com
Cc: DJ Delorie <dj@...hat.com>
Subject: RFC: open_memstream, fseek, and SEEK_END.
DJ Delorie and I reviewed the following reported bug regarding
open_memstream() behaviour and decided that the POSIX behaviour
was under specified when it came to computing the position of
SEEK_END in certain conditions.
I would like to get consensus on what the behaviour should be.
DJ is going to open an Austin Group ticket to request a clarification.
Bug 1875596 - fwrite on stream opened with open_memstream() truncates the buffer size
https://bugzilla.redhat.com/show_bug.cgi?id=1875596
Musl (recent):
Running test: open_memstream()
position after fwrite: 24
position after SEEK_END: 24
open_memstream() final buffer size: 4
glibc (recent):
Running test: open_memstream()
position after fwrite: 24
position after SEEK_END: 4
open_memstream() final buffer size: 4
FreeBSD 12.1:
Running test: open_memstream()
position after fwrite: 24
position after SEEK_END: 24
open_memstream() final buffer size: 24
My own notes regarding the behaviours:
- The most important behaviour of an open_memstream is that the
management of the current file position indicator is crucial
to the user and the management of the backing store. The user
must use ftell() and fseek(SEEK_SET) to keep the file position
indicator where they expect it before calling fflush() or
fclose() to finalize the buffer.
- FreeBSD computes the wrong final buffer size. The standard
is clear that it should be the "smaller of" the current
buffer length, or the number of bytes between the
beginning of the buffer and the current file position indicator.
- glibc and musl disagree about where SEEK_END lies and the
standard does nothing to clarify this.
- Should SEEK_END always seek to the current file position
indicator? My opinion is that the behaviour of fflush()
and fclose() strongly implies that SEEK_END should always
move to the file position indicator which is where the
end of the buffer will be should an fflush() or fclose()
be called next. As a developer you may want to know where
the last write completed, go there, and continue adding
data. This behvaiour seems more important than say
finding the extent of the buffer (see next point).
- An alternative argument can be made that the user has no
way to find out the current extent of the buffer without
the ability to call fseek(SEEK_END) + ftell() and get back
the maximum size the current buffer has been extended to.
One alternative is to call strlen() on the buffer to find
this size since you're always null terminated, but this
is costly on large sized buffers if you don't keep track
of this position via ftell() yourself.
I'm looking for input on the direction we might take the
standard or the implementations.
--
Cheers,
Carlos.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
