From owner-freebsd-current@freebsd.org Thu Aug 10 13:25:23 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5610DD2987 for ; Thu, 10 Aug 2017 13:25:23 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by mx1.freebsd.org (Postfix) with ESMTP id 70FC5861; Thu, 10 Aug 2017 13:25:23 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 7F39116051; Thu, 10 Aug 2017 15:25:22 +0200 (CEST) Date: Thu, 10 Aug 2017 15:26:28 +0200 From: Steffen Nurpmeso To: Bryan Drewery 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> Mail-Followup-To: Bryan Drewery , freebsd-current@freebsd.org, Steffen Nurpmeso User-Agent: s-nail v14.9.3-dirty OpenPGP: id=232C220BCB5690A37BD22FFDEB66022795F382CE; url=https://www.sdaoden.eu/downloads/steffen.asc BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 13:25:23 -0000 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)