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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15413 invoked from network); 6 May 2023 17:55:13 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 6 May 2023 17:55:13 -0000 Received: (qmail 20060 invoked by uid 550); 6 May 2023 17:55:09 -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 20028 invoked from network); 6 May 2023 17:55:09 -0000 X-Virus-Scanned: SPAM Filter at disroot.org Date: Sat, 6 May 2023 23:55:27 +0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1683395696; bh=j5yo42kZpvlzjmArnRxatsd83FtliU8FTYoy9rOE9OM=; h=Date:From:To:Subject:References:In-Reply-To; b=UertJ3dbudF8Gb/QaJVI3yaraX41PBuhvBL9/+zm1c081PWEnVbVjIXgu46bb2oH5 5P0mSN4vMg1dckGCKeeMEaETGwkpoHSnjF6xqWFUFQae5N8TY7STkeuR7n1MxYRpID pZy/RW+l+ATeJQzxtf3EV0UdzmzIMXJW7lhKz+7VX8EabRes1MutbQORtEnMmpAl0i wX4pCDriqleEpjc+j6OhpNSVs3CeiDpb5L3zTEKvQAjVwctF0dAo/SnLE2OKKIZXWR uwdUXMozV4q7FRol3KGvnMgqjbmlQsW5E4QtwphL6dIFv0MKcHOtHHS8Cw34/2UpWc UIeJT9Li2Au9g== From: NRK To: musl@lists.openwall.com Message-ID: <20230506175527.ic4ibgxo6e7mquq4@gen2.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [musl] Question: Why vfprintf call twice printf_core? On Sat, May 06, 2023 at 08:25:25AM +0200, Markus Wichmann wrote: > If you're looking for performance, however, I suggest steering clear of > the printf() family of functions. They contain complex logic that is > typically way overpowered for common needs, and just straight string > manipulation will always be faster. Agreed. However... > E.g. the above call could be turned into > > strlcpy(buf, "this is a more typical error message with detail: ", sizeof buf); > strlcat(buf, "No such file or directory", sizeof buf); strcat (and friends) are the opposite of performance: https://en.wikipedia.org/wiki/Joel_Spolsky#Schlemiel_the_Painter.27s_algorithm Better alternative: have your string copy function return a pointer to the nul-byte. This pointer can be both used for efficient concat as well as determining the string length. Example using POSIX stpcpy(3) (minus bounds checking): char *p = stpcpy(buf, "this is a more typical error message with detail: "); p = stpcpy(p, "No such file or directory"); write(2, buf, p - buf); Additionally, consider getting rid of nul-strings altogether and only use them in interface boundaries that require them. - NRK