From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 94F52384773A for ; Tue, 5 Dec 2023 16:39:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 94F52384773A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 94F52384773A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701794390; cv=none; b=kKr5h6x1O1LxApSNxLnn/D6hfhRsL77nQOPw/Rm9V//3IMrIYUOROfFEp0oLuQ31J0oUUwkOe8ZqDiudKmSQzbUKWKobgFDq7UIUC5lxVZYSB2Za/t97b+LHEKYWw1RMjXdGyreMMYnd+BLXuR1IUxN64Q5yCo3Cnz+i1PEn7Xg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701794390; c=relaxed/simple; bh=ZFkQAORXPS+BMKMrnqiN+YRr6X4KTsBfjt/jq3SkHVM=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=hy48J0K5irhlE49zTJiM79T754upzTJeYGcYdQKMnWqt136O3YoWnHAVC2sjFMoOAswIV5Scen4MpSMEiBU1oA5HwlxzCR79kchXhgOXamWRYCIXFJC7zjM+g/tx4hQ/M3meGdRkbkSB8ThiqoUQ/7rIPvEbaAR8eXPg4E7Tx9s= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DEB62139F; Tue, 5 Dec 2023 08:40:35 -0800 (PST) Received: from [10.57.5.1] (unknown [10.57.5.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BEB463F6C4; Tue, 5 Dec 2023 08:39:48 -0800 (PST) Message-ID: <6172a3a7-724d-42d8-b464-cabd3deacf8a@foss.arm.com> Date: Tue, 5 Dec 2023 16:39:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] strchr, strchrnul: implement strchr() as strchrnul() Content-Language: en-GB To: James , newlib@sourceware.org Cc: "vinschen@redhat.com" References: <20231205145839.474295-1-tirtajames45@gmail.com> From: Richard Earnshaw In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3489.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 05/12/2023 15:52, James wrote: > Currently, strchrnul() is implemented as strchr() and falls back to a > strlen() to find the null-terminator if the character is not > found, scanning the string twice. However, strchr() is going to scan the > whole string anyway and discard the pointer to the null-terminator if > the character is not found, returning NULL. > > Instead, we can just implement strchr() with discarding strchrnul()'s > pointer to null-terminator returning NULL and by that avoid calling > strlen() in strchrnul() if a character is not found. > > I made a typo in the strchr(), it should be: >   return s1 && *s1 ? (char *) s1 : NULL; > which should be: >   return *s1 ? (char *) s1 : NULL; > since strchrnul will never return NULL. > > We can avoid the strchrnul() function call in strchr() by implementing > it in a separate header like str-two-way.h and including them in both > files. The same could be done with the strlen() part in strchr() since > the implementations look to be the same. strchrnul is not standard, it's a GNU extension. So technically, it should be possible to redefine strchrnul to something else and strchr should still work as expected. The other issue is that many ports implement strchr in assembly for performance and rely on strchrnul calling that to avoid having too many functions implemented in assembly. So I'm not convinced this is a good idea. R.