Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.