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.