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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 13450 invoked from network); 24 Feb 2023 14:17:47 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 24 Feb 2023 14:17:47 -0000
Received: (qmail 21832 invoked by uid 550); 24 Feb 2023 14:17:45 -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 21792 invoked from network); 24 Feb 2023 14:17:44 -0000
X-Virus-Scanned: SPAM Filter at disroot.org
Date: Fri, 24 Feb 2023 20:17:31 +0600
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail;
	t=1677248251; bh=/gwX9Qm0IHE1khguXeTwsd3L7LXhFyzKUOEuh6pLFi4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To;
	b=UN0YS3HVeKXwgDzWxHO9/urcc743XAn4pAk8hQ2xCWiEXRdgM+oD11mQx8Uk4hzAM
	 KO2fQMBqqdHYVS8TMioopiwnd8IPEzbOQ211STi7WNBkqQjhJGL0GkZohB9s4Wbpw5
	 kCaUOJc/rUD1PcVgnCY9/7Ps5gwhLnp9RmZdrgdb8CNo09lBBesAB0l8CCT/lohSK2
	 pJUq4lsPRAcdN+1kG0Fx682fqP60r7oliHn+TmoUZgxoVp2YgJ1L77o6TvpCCzuBMf
	 AjuzW2WHsh1FdftPoV5fid/YMi1lyQduFLlxGjs5A74wqaY8GWtbM2OND9Nw11k/F3
	 unAerhfLHj9yQ==
From: NRK <nrk@disroot.org>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com, Tamir Duberstein <tamird@google.com>
Message-ID: <20230224141731.dm4w7fbfkczbx42e@gen2.localdomain>
References: <CAK-_uh7=5Ea3pESgEiDjWHifpe+x3w3-ccpDupz6d9ksyGqXLA@mail.gmail.com>
 <20230224133413.GE4163@brightrain.aerifal.cx>
 <20230224135511.iunglqtcvpjeqgtv@gen2.localdomain>
 <20230224140739.GF4163@brightrain.aerifal.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230224140739.GF4163@brightrain.aerifal.cx>
Subject: Re: [musl] undefined behavior in fread.c

On Fri, Feb 24, 2023 at 09:07:41AM -0500, Rich Felker wrote:
> 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.

OK, I see. Wasn't aware of that.

On a sidenote, if I'm reading the right function (libio/iofread.c) then
glibc is taking the lock _after_ they do the size check.

	  if (bytes_requested == 0)
	    return 0;
	  _IO_acquire_lock (fp);
	/* ... */

- NRK