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 22220 invoked from network); 24 Feb 2023 20:07:36 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 Feb 2023 20:07:36 -0000 Received: (qmail 31886 invoked by uid 550); 24 Feb 2023 20:07:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 31854 invoked from network); 24 Feb 2023 20:07:31 -0000 Date: Fri, 24 Feb 2023 15:07:19 -0500 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: Tamir Duberstein , musl@lists.openwall.com, NRK Message-ID: <20230224200718.GG4163@brightrain.aerifal.cx> References: <20230224133413.GE4163@brightrain.aerifal.cx> <20230224135511.iunglqtcvpjeqgtv@gen2.localdomain> <20230224140739.GF4163@brightrain.aerifal.cx> <20230224141731.dm4w7fbfkczbx42e@gen2.localdomain> <20230224151334.ycgddzdc4o5a4m5q@gen2.localdomain> <20230224174010.7b8e2401@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230224174010.7b8e2401@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] undefined behavior in fread.c On Fri, Feb 24, 2023 at 05:40:10PM +0100, Jā‚‘ā‚™ā‚› Gustedt wrote: > > on Fri, 24 Feb 2023 11:12:11 -0500 you (Tamir Duberstein > ) wrote: > > > I agree, the caller's behavior is UB. I'll send them (freetype2) a > > patch. > > > > That said, do we want to avoid internal UB here anyway? > > I am not sure that I even understand what "internal UB" is supposed to mean. > > > - As mentioned earlier, glibc avoids the UB (and the lock). > > - llvm-libc does the same starting with > > https://github.com/llvm/llvm-project/commit/53c251b > > - uclibc avoids the UB but still locks: > > https://github.com/gittup/uClibc/blob/9dbf00b/libc/stdio/fread.c#L25 > > - FreeBSD avoids the UB but still locks: > > https://svnweb.freebsd.org/base/head/lib/libc/stdio/fread.c?view=markup#l76 > > - Android (bionic) avoids the UB but still locks: > > https://cs.android.com/android/platform/superproject/+/master:bionic/libc/stdio/stdio.cpp;l=1099;drc=4aa8f499f21ebf84101de34d68682d5388667001 > > > > Does this persuade? > > Me personally not much. The only thing that would help applications to > write portable code is to put an attribute on the pointer argument > such that bad calls get diagnosed if possible. Likewise. The recent atol thread seems relevant, where my view was that it's better to allow the overflow to happen when the caller invokes UB by passing an argument that overflows, so that a libc built with sanitizers would naturally cause a trap. The same applies here. If we make no change, a libc built with sanitizers would automatically trap when NULL is passed to fread. Rich