From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12520 Path: news.gmane.org!.POSTED!not-for-mail From: Andrew Bell Newsgroups: gmane.linux.lib.musl.general Subject: Re: fwrite() - possible division by zero Date: Wed, 14 Feb 2018 16:47:46 -0500 Message-ID: References: <20180214193942.nar6nvuulv4rg5nt@voyager> <20180214200707.hvbwbn733gwvtkbq@voyager> <20180214211523.GC4418@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114e632ad579c50565330f4e" X-Trace: blaine.gmane.org 1518644787 17144 195.159.176.226 (14 Feb 2018 21:46:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Feb 2018 21:46:27 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12537-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 14 22:46:22 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1em4sG-0002cj-BQ for gllmg-musl@m.gmane.org; Wed, 14 Feb 2018 22:45:56 +0100 Original-Received: (qmail 12127 invoked by uid 550); 14 Feb 2018 21:47:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 12101 invoked from network); 14 Feb 2018 21:47:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=uufHTB08vHfxqz4w9irOcDNkF9OmeO24XrQ5bRcCeRk=; b=LqpftCrCEi55otlC0RocD5P0zw3E0m7qUQrIRfrzh9S94OygzcAQNASXwFnLeqlyp8 xU7MNLuVl3YsujqfSmENqb/5SZkG/WyrpOf5oddeOpCik1puU4YI/Btk0ckRno6Wq/RA Xvg8a9+Mb3zQmhDdkKM8Dz77FNVwCdpVvrQ0CbGDkB6A6Q+dqdwOJjv+GHR9HdaHzQek 6Q0tcxH5QNBew7J3DJcSsXq9PSdCmJoKqGiGgpe/7isWyEqqgT77wJ0OLtA6JGMBr75I QDNSqtLmricP9ySY2fHpRm9XfqU1qcFlmaQsJFM2CrVgDQC6H96jkVgLkGrz1kTOcrmF sLVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=uufHTB08vHfxqz4w9irOcDNkF9OmeO24XrQ5bRcCeRk=; b=e79DYmuicN6RhdyUKMy2K3nuX8Rknb/0q8GP3uzRXuK1OmpyLhag+PM33vssu+l3GT emNTkZ+TmOTR8Gpj6XKhd22ViyCJagQmscSnSJBJAyZuBrtbshSuYXMqOS1L2yp97MtS GZam0sJ5a1XG0kouxf6a6GMt3JitFlduL8Cq8pyHYcOUqPoGbfSt6dZHC8DYsHuSQSES bJsa6nSpLeK6dznsL6glvQm+AVFaNZGsYK0QMzOlvMMUevMzKOXG6C9S36KzpWEr4/17 fkk3OZXfSVr9UYxsNkkfUf9g1fjU9iLa/FHlWAvP2R1wbBgDPJOLFpBVbCh8ExSdkl4w vysw== X-Gm-Message-State: APf1xPAAG/86EI4e/ZotnWbuYDpk7/TVI56xH/zKhEotm/aFbsuCbTbK e7DaTB6MwNKWJ2fwPrqjw8XZnRyb0YR/DfJ4d1uPiWbp X-Google-Smtp-Source: AH8x224T3X9fRmrtSIl+BxVmD9HFj0HfYhNGGuwUmOJ5wF9Nuq+jJ3XDUdGWM28s5dAb7YIafai2d38kLKkVcJ6TZBQ= X-Received: by 10.55.94.4 with SMTP id s4mr867969qkb.156.1518644866937; Wed, 14 Feb 2018 13:47:46 -0800 (PST) In-Reply-To: <20180214211523.GC4418@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:12520 Archived-At: --001a114e632ad579c50565330f4e Content-Type: text/plain; charset="UTF-8" On Wed, Feb 14, 2018 at 4:15 PM, Szabolcs Nagy wrote: > * Andrew Bell [2018-02-14 15:11:34 -0500]: > > On Wed, Feb 14, 2018 at 3:07 PM, Markus Wichmann > wrote: > > > > > On Wed, Feb 14, 2018 at 02:48:14PM -0500, Andrew Bell wrote: > > > > Why not early return if size == 0 and avoid the call to __fwritex > > > > altogether? > > > > > > > > > > Because it's a rare corner case? Here, there's also locking correctness > > > to consider: fwrite() has to block until f is unlocked, irrespective of > > > parameters. So there's no real benefit to doing an early return. > > > > > > > But it's already being checked to set nmemb to 0. Couldn't you just > return > > 0 and avoid the lock as well? > > the lock must not be avoided. > > otherwise fwrite would make progress on a FILE locked by > another thread which is non-conforming. That's not how I read this: http://port70.net/~nsz/c/c11/n1570.html#7.21.2p8 "All functions that read, write, position, or query the position of a stream lock the stream before accessing it. They release the lock associated with the stream when the access is complete." When size == 0, the FILE doesn't need to be accessed so no lock should be necessary. Perhaps language of this document has been superseded? But it doesn't much matter. It just seemed to make the code more clear to me and would have avoided the initial question. Best, -- Andrew Bell andrew.bell.ia@gmail.com --001a114e632ad579c50565330f4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Wed, Feb 14, 2018 at 4:15 PM, Szabolcs Nagy <nsz@port70.net>= wrote:
* Andrew Bell = <andrew.bell.ia@gmail.com> [2018-02-14 15:11:34 -0500]:
> On Wed, Feb 14, 2018 at 3:07 PM, Markus Wichman= n <nullplan@gmx.net> wrote: >
> > On Wed, Feb 14, 2018 at 02:48:14PM -0500, Andrew Bell wrote:
> > > Why not early return if size =3D=3D 0 and avoid the call to = __fwritex
> > > altogether?
> > >
> >
> > Because it's a rare corner case? Here, there's also locki= ng correctness
> > to consider: fwrite() has to block until f is unlocked, irrespect= ive of
> > parameters. So there's no real benefit to doing an early retu= rn.
> >
>
> But it's already being checked to set nmemb to 0.=C2=A0 Couldn'= ;t you just return
> 0 and avoid the lock as well?

the lock must not be avoided.

otherwise fwrite would make progress on a FILE locked by
another thread which is non-conforming.


"All functions that read, write, po= sition, or query the position of a stream lock the stream before accessing = it.
They release the lock associated with t= he stream when the access is complete."

When size =3D=3D 0, the FILE doesn&#= 39;t need to be accessed so no lock should be necessary.
Perhaps langua= ge of this document has been superseded?

But it do= esn't much matter.=C2=A0 It just seemed to make the code more clear to = me and would have avoided the initial question.

Be= st,

--
Andrew = Bell
andre= w.bell.ia@gmail.com
--001a114e632ad579c50565330f4e--