Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Aug 2017 15:24:23 +0200
From:      Steffen Nurpmeso <steffen@sdaoden.eu>
To:        Bryan Drewery <bdrewery@FreeBSD.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Would O_APPEND for /dev/null be possible?
Message-ID:  <20170810132423.-8jw-%steffen@sdaoden.eu>
References:  <20170807213656.FwzOG%steffen@sdaoden.eu> <768c55f1-6a10-868b-9cd5-6ca5f93aaca3@FreeBSD.org> <20170809212144.Qx0Yr%steffen@sdaoden.eu>

next in thread | previous in thread | raw e-mail | index | archive | help
i wrote:
 |Bryan Drewery <bdrewery@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)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170810132423.-8jw-%steffen>