From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mengyan1223.wang (mengyan1223.wang [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 6FCC83857831 for ; Fri, 9 Jul 2021 16:12:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6FCC83857831 Received: from [IPv6:240e:35a:108d:3c00:dc73:854d:832e:3] (unknown [IPv6:240e:35a:108d:3c00:dc73:854d:832e:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@mengyan1223.wang) by mengyan1223.wang (Postfix) with ESMTPSA id C10C166874; Fri, 9 Jul 2021 12:12:06 -0400 (EDT) Message-ID: Subject: Re: strlen From: Xi Ruoyao To: "Alejandro Colomar (man-pages)" , Jonny Grant , Segher Boessenkool Cc: gcc-help@gcc.gnu.org, linux-man , Florian Weimer , Michael Kerrisk Date: Sat, 10 Jul 2021 00:11:47 +0800 In-Reply-To: References: <87363whf2z.fsf@mid.deneb.enyo.de> <48e874cb-2b95-2783-ddfc-ae12d9aaf8f5@jguk.org> <87bl7fozxi.fsf@mid.deneb.enyo.de> <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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3032.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 16:12:16 -0000 On Fri, 2021-07-09 at 16:17 +0200, Alejandro Colomar (man-pages) via Gcc-help wrote: > Hi Jonny, Segher, > > 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. > > > > > inline size_t safestrlen(const char * s) {return s?strlen(s) : 0} > > > > Perhaps there are too many email addresses on this cc list now. I think the discussion at least has nothing to do with linux-man or gcc- help: man pages just describe the existing API (C or POSIX or Linux specific), and GCC just compiles code and doesn't care what the API is. Neither is a place to discuss "how to design an API". And I think Jonny should discuss the API design with the users of his API (maybe his collegue or downstream developers), instead of some random guys in mail list. The users are the ones who will call his function anyway so it's better to choose an API they like. Yes, Jonny can "force" the users to do something for safety, but this decision should also be discussed with them and documented. Or they won't understand the decision, and may "invent" or "improvise" some "new wheels", breaking Jonny's design. For example, I don't like a function silently treats NULL as an empty string. I prefer a function to abort() or print a log "strlen_checked() is called with NULL, there is a bug in your code" when I (mis)use NULL. But it's just my 2 cents: if the potential users of the API agree the function to act as that, then it's good to go. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University