Open questions for POSIX Issue 8

Open questions for POSIX Issue 8

[Eric Blake]

Hello glibc developers,

The Austin Group is getting closer to wrapping up Issue 8 of POSIX,
but still has some open bug reports where feedback from the glibc
perspective would be useful.  Here's a link to the bugs; it may be
easiest if you supply any comments directly to the relevant bugs in
the Austin Group database, but if that is not practical for you, I
don't mind adding comments to those bugs with links or quotes back to
comments you make in reply to this email thread.

https://austingroupbugs.net/view.php?id=618
  errno in various pty functions
  Older versions of POSIX let some functions like isatty, grantpt,
... return errors without setting errno.  Are we now at the point
where it would be portable for POSIX Issue 8 to mandate errno values
for all possible failures?  And if so, are there situations where
portable code must be prepared for different errno values from
different implementations even for the same error scenario?

https://austingroupbugs.net/view.php?id=1406
  open_memstream and SEEK_END
  Implementations appear to differ on how the end of a memory stream
is manipulated when seeking past the end.  Would the following wording
in Issue 8 be compatible with glibc, while still pointing out the fact
that other implementations have done things differently?

"The fseek() and fseeko() functions can be used to set the file
position beyond the current buffer length. It is
implementation-defined whether this extends the buffer to the new
length. If it extends the buffer, the added buffer contents shall be
set to null bytes for open_memstream(), or null wide characters for
open_wmemstream(); if it does not extend the buffer, then if data is
later written at this point, the buffer contents in the gap shall be
set to null bytes for open_memstream(), or null wide characters for
open_wmemstream(). If fseek() or fseeko() is called with SEEK_END as
the whence argument, it is implementation-defined whether the file
position shall be adjusted either relative to the current buffer
length or relative to the buffer size that would be set by an fflush()
call made immediately before the fseek() or fseeko() call."

https://www.austingroupbugs.net/view.php?id=657
  fmemopen and NUL bytes
  Similar to the open_memstream issue; POSIX wording (originally
copied from glibc) was ambiguous enough that existing implementations
now differ on behavior.  But here, we don't yet have a wording
proposal, and would welcome feedback at settling on something that
matches existing practice across platforms while still pointing out
the pitfalls to applications using the interface.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org