From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB4BFC07E99 for ; Sat, 10 Jul 2021 01:05:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C51516120D for ; Sat, 10 Jul 2021 01:05:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229703AbhGJBHu (ORCPT ); Fri, 9 Jul 2021 21:07:50 -0400 Received: from gate.crashing.org ([63.228.1.57]:49549 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229506AbhGJBHu (ORCPT ); Fri, 9 Jul 2021 21:07:50 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 16A10uGQ009000; Fri, 9 Jul 2021 20:00:56 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 16A10sAY008999; Fri, 9 Jul 2021 20:00:54 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 9 Jul 2021 20:00:54 -0500 From: Segher Boessenkool To: "Alejandro Colomar (man-pages)" Cc: Jonny Grant , gcc-help@gcc.gnu.org, linux-man , Florian Weimer , Michael Kerrisk Subject: Re: strlen Message-ID: <20210710010054.GY1583@gate.crashing.org> References: <23679a28-5986-0af2-4d98-7de68ed0deec@jguk.org> <53b3666b-d200-ef97-b050-cc38669c61cd@gmail.com> <564825ed-1e1f-b344-da35-1b83c551ed5f@jguk.org> <5566b180-1333-d73b-22ee-6c6d32053921@jguk.org> <20210708234929.GU1583@gate.crashing.org> <3ddd0291-04d2-b35a-ce81-034bb0d9392a@jguk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org Fine, I'll bite :-) On Fri, Jul 09, 2021 at 04:17:08PM +0200, Alejandro Colomar (man-pages) wrote: > On 7/9/21 3:54 PM, Jonny Grant wrote: > >Yes, this could work. But it does rely on programmer typing it like that > >every time... Maybe an inline function better. > > I agree on that. A function (or any other abstraction) can be fine for this, *iff* you can make people use it correctly. Since it is pretty much impossible to give a good succinct name to this function, I posit that is not the case. Please feel free to prove me wrong (by coming up with a decent name for it). > >I'd prefer a Annex K of C11 style function ISO/IEC TR 24731-1 for strlen() > >- but there isn't one such as strnlen_s. > > Please, consider not calling some function safesomething() or similar, > as it isn't 100% safe. It's like calling some thing "the new X". How > will you call the next version? "the nova X"? And the next? "the > supernew X"? > > As I said before, unsigned types are unsafe, you may want to accept it > or not, but they are. I thought Annex K was great entertainment, but calling unsigned types "unsafe" takes the cake. Unsigned types are Z/nZ with n some power of two. Signed types are not even Z (overflow is undefined). Unsigned types are useful for describing many machine things. They are useful for sizes, not only because sizes cannot be negative, but also because sizes can be bigger than the maximum positive number that can fit in the same size signed number. They are useful for bitty things, registers maybe, stuff in memory, or device I/O registers. And they are much more useful than C signed numbers for holding memory addresses, where you need that (you can do sane aritmetic on it). Using unsigned types without range checking is often wrong ("unsafe" in your words). Using signed types without range checking is just as wrong in the same cases, if not more (overflow is undefined). At least in the "unsigned" case it is *possible* its behaviour is what the programmer intended! > Agree on this again, but I think the following is readable: > > len = strlennull(maybenull); If you use it a million times, of course you can give it a short and non-sensical name, and expect the users to learn what it means. If not, it is better to be slightly more verbose, and reduce the mental load. Segher