From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 12349 invoked from network); 24 Feb 2023 14:07:57 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 24 Feb 2023 14:07:57 -0000
Received: (qmail 11371 invoked by uid 550); 24 Feb 2023 14:07:54 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 11329 invoked from network); 24 Feb 2023 14:07:53 -0000
Date: Fri, 24 Feb 2023 09:07:41 -0500
From: Rich Felker <dalias@libc.org>
To: NRK <nrk@disroot.org>
Cc: musl@lists.openwall.com, Tamir Duberstein <tamird@google.com>
Message-ID: <20230224140739.GF4163@brightrain.aerifal.cx>
References: <CAK-_uh7=5Ea3pESgEiDjWHifpe+x3w3-ccpDupz6d9ksyGqXLA@mail.gmail.com>
 <20230224133413.GE4163@brightrain.aerifal.cx>
 <20230224135511.iunglqtcvpjeqgtv@gen2.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230224135511.iunglqtcvpjeqgtv@gen2.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] undefined behavior in fread.c

On Fri, Feb 24, 2023 at 07:55:11PM +0600, NRK wrote:
> On Fri, Feb 24, 2023 at 08:34:14AM -0500, Rich Felker wrote:
> > Is there any indication that passing NULL as the first argument to
> > fread is not itself undefined?
> 
> C99 says the following:
> 
> | If size or nmemb is zero, fread returns zero and the contents of the
> | array and the state of the stream remain unchanged.
> 
> It doesn't explicitly mention weather stream can be NULL or not in case
> of 0 size/nmemb - but regardless, is there any actual reason for not
> returning early?
> 
> The following should be OK as far as I see:
> 
> -	if (!size) nmemb = 0;
> +	if (!size || !nmemb) return 0;
> 
> or `if (!len) return 0;` could also work if multiplication overflow is
> not a concern.

stdio functions are required (by POSIX) to behave as if they take a
mutex on the FILE. If fread with a length of zero makes forward
progress when another thread holds the lock, this is non-conforming.

Rich