Date: Thu, 10 Aug 2017 15:26:28 +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: <20170810132628.bhY84%steffen@sdaoden.eu> References: <20170807213656.FwzOG%steffen@sdaoden.eu> <768c55f1-6a10-868b-9cd5-6ca5f93aaca3@FreeBSD.org> <20170809212144.Qx0Yr%steffen@sdaoden.eu> <20170810132423.-8jw-%steffen@sdaoden.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
and i wrote: ... |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.) Also, the return of fseek(3) is "int", so testing LONG_MAX looks a bit odd as such, from my point of view? 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?20170810132628.bhY84%steffen>