Would O_APPEND for /dev/null be possible?

[Steffen Nurpmeso]

i wrote:
 |Bryan Drewery <bdrewery at FreeBSD.org> wrote:
 ||On 8/7/2017 2:36 PM, Steffen Nurpmeso wrote:
 ||> I can open a file with "a+", which, for this software, means
 ||> "O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and
 ||> OpenBSD, but FreeBSD complains, i think because O_APPEND.  (I
 | ...
 ||> openat(AT_FDCWD,"/dev/null",O_RDWR|O_APPEND|O_NOFOLLOW|O_CREAT,0377777625\
 ||> 2\
 ||> 0) = 3 (0x3)
 ||
 ||Seems to work fine.
 ..
 |locking, so i thought ...  Hmm, this is even more complicated than
 |i thought, wait, i have to debug that.  And: it turns out that
 |a fseek(3) on the descriptor opened not only fails but sets the
 |ferror(3) state of the FILE!  I would need to look into the
 |standard whether this behaviour is correct, but in any case we are
 |not prepared for that, and neither of Linux, Solaris nor OpenBSD
 |enter this condition.

The POSIX standard says that the error condition shall be set if
a read or write error occurs only, but this should not be the case
here, no?  So looking at [master]:lib/libc/stdio/fseek.c:_fseeko()
(note my machine is not strong enough to compile any compiler (but
pcc, tcc) or even operating systems, i cannot verify) there is
only one condition where the stream error indicator is set, after
the dumb: label.

I would expect the error indicator for a failing __srefill() or
__sflush() (only: not following branches), but _here_ it is set
for a "long overflow" check failure.  This looks wrong to me, but
of course: without having any idea nor test possibilities.  Also
note this is 32-bit FreeBSD, can it be that /dev/null -2L,SEEK_END
sees enters 64-bit range?  That also feels wrong, for /dev/null
anyway, where it should not matter and simply succeed.  (The
tested OpenBSD was 32-bit, too.)

Ciao!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)