From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E94034B1AB for ; Sat, 7 Mar 2026 11:37:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772883459; cv=none; b=p320+dSnQkBOwW9J8UqT99gyplBdXDL1AbhQ2HeiER/lZHAQ0cDuUgQfRNJdTkhpMbt7ggYvQih04Ab9D91j+6ZEhhDakBcb33keiWaSJWYRs4rCcLHCHmUsm1AWibqUEqG9AR1RDJoohoeFsD/tBY8BloFrJcMHTLrST/w7J9U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772883459; c=relaxed/simple; bh=hFPaRynW5WkEbLvkegGAIxm57vnaWtEUlilJmopzgGA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fgWF9nuBlFzYFKDxPyOK5UgMLsfdIRyet/AQ66orKwv9VHhx5yNxN1ULGr8ZXI0wm25T+cP1UFJTPHDvZTrfK/WMW5nX+5v1T3mcpvjFgC/XkrWhJjqNS0toLYZ2ybkBJkp/eFUDVnRp1YNZJLM7VuzDqgb4QWaQ0iLMbHvfCs0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=SlBELrUh; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="SlBELrUh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1772883455; bh=qDw24nJwEnJ4IB5IVlghZcUGj1h2PoRkh3lD1rYCp2g=; h=From:Message-ID:From; b=SlBELrUhFiW+7VagUaVAW7wxWwMKRZZkBufVsz+25L/5a4bXk2YkkbawVY2+ccfbr 6zeISukTlZdpxt5xR3DrqOzVlZDNvslDnKy4Nr5J8WqDhX/EbiQCRnSLv2T92a3NZt kBcD4rsT382bR+IWT1SnhjCpzF0PfST8DbYh7Kew= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id AC322C091E; Sat, 07 Mar 2026 12:37:35 +0100 (CET) Date: Sat, 7 Mar 2026 12:37:35 +0100 From: Willy Tarreau To: David Laight Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= , linux-kernel@vger.kernel.org, Cheng Li Subject: Re: [PATCH v4 next 09/23] tools/nolibc: Implement strerror() in terms of strerror_r() Message-ID: References: <20260302101815.3043-1-david.laight.linux@gmail.com> <20260302101815.3043-10-david.laight.linux@gmail.com> <20260307113105.76fb7fe9@pumpkin> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260307113105.76fb7fe9@pumpkin> On Sat, Mar 07, 2026 at 11:31:05AM +0000, David Laight wrote: > On Sat, 7 Mar 2026 11:18:41 +0100 > Willy Tarreau wrote: > > > Hi David, > > > > On Mon, Mar 02, 2026 at 10:18:01AM +0000, david.laight.linux@gmail.com wrote: > > > From: David Laight > > > > > > strerror() can be the only part of a program that has a .data section. > > > This requres 4k in the program file. > > > > Thanks for handling this one! Indeed, I saw a trivial hello world program > > take 4kB once %m got supported, which is a shame. > > > > > Add a simple implementation of strerror_r() (ignores buflen) and use > > > that in strerror() so that the "errno=" string is copied at run-time. > > > Use __builtin_memcpy() because that optimises away the input string > > > and just writes the required constants to the target buffer. > > > > > > Ignoring buflen is unlikely to be a problem given that the output is > > > always short. > > > > On this point it's not necessarily true, as we can overflow too short > > an output, e.g. when calling strerror_r() on a single-byte buffer: > > But that would be silly, and you get what you deserve :-) > It's not like passing char[64] will be too short because of some overlong > error text. Yes I know and I also hate having to write code to defend against silliness, but sometimes what looks silly to some in fact looks smart to others. You could for example find it stupid to call snprintf() with a zero-length but it's actually used sometimes to figure the size to allocate. > > > +static __attribute__((unused,)) > > > +int strerror_r(int errnum, char *buf, size_t buflen __attribute__((unused))) > > > +{ > > > > Here I think we can simply do this to comply with the man page: > > > > if (buflen < 18) { > > errno = ERANGE; > > return -1; > > Looks like it should 'return ERANGE' (matching glibc 2.13+). Ah you're right, I initially misunderstood the man page as "a positive number with errno set". But yes, returning ERANGE is fine! > > (and we can safely ignore it for strerror()). > > ISTR strerror_r() tends to get inlined into strerror() so it > would be optimised away. That's what I suspected as well. > That simple (slightly over-enthusiastic) check is probably fine. > Especially since normal code will be expecting a much longer string. > > I did think of implementing strerror_r() as: > return snprintf(buf, buflen, "errno=%d", errnum) < buflen ? 0 : ERANGE; > but that seems excessive. Yes ;-) Willy