From owner-freebsd-current@freebsd.org Thu Aug 10 13:23:20 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 5B631DD2893 for ; Thu, 10 Aug 2017 13:23:20 +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 27F58677; Thu, 10 Aug 2017 13:23:19 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id CE6DF16051; Thu, 10 Aug 2017 15:23:17 +0200 (CEST) Date: Thu, 10 Aug 2017 15:24:23 +0200 From: Steffen Nurpmeso To: Bryan Drewery 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> 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:23:20 -0000 i wrote: |Bryan Drewery 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)