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,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25319 invoked from network); 6 May 2023 06:25:41 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 6 May 2023 06:25:41 -0000 Received: (qmail 7844 invoked by uid 550); 6 May 2023 06:25:38 -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 7804 invoked from network); 6 May 2023 06:25:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1683354326; i=nullplan@gmx.net; bh=zixpMUfuNWzuy5qc3XTxli0SMLe0xNg8ztDRLVZGKNg=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=B7MU0Smm94aWn7rm+uwKbcWO8HZ5ToD/ONfxCXbhUD6s38YqYOX6UyaZiHxqBcypn JErhHBH920YgTb1F0cP3+BEN2ureF9ReNBXaPlxpCDIMt+bxJaSauHSSF1gOmbXSAz NR7XB9B7uXAag7jsp8N4bVkvJpXbsQi5KH2f29C0/cLDyOIL1BNW0yGlT8KJJf/0h9 j5C8k5bYKYAJNfnhxUeNLKM2JKeZThQ7iz5n8KQ24w+8Rn0uAsIYKJzSPRiAlTInFS JlSs6AvKVLXRLgSF6I44P5qVn6pZlNOC/sHoxQp4QlAdwVfMc4l2lbfJ0k24iEryPh RpfTxSa2KO4Cw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Sat, 6 May 2023 08:25:25 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Provags-ID: V03:K1:ZvWJha8i+0TpQZvN+f8KDQXPNXNa9iQPSDJucqYy2unterGT/+B Xc5XoykhtG/f59OUoMZb8tA/IKSlm8VKsaePSE+MbTw5uxxXVPG2TS3xgt6yCrCUvqYng24 KVyaGx291lXOmAQA62FbySt6SzOtFj0PbCD8mpFLl6tdUXXyUjVOCCSs/aRzzruJgHldmdb plmG1F+qvgF5uYUIzJvxA== UI-OutboundReport: notjunk:1;M01:P0:f1cZqrQpW+Q=;a2u2VUK+EhuHGZeE+mU/t0kaV0f cFOSxBovQxmJbIgKBHiGsZopeWo8kTfAPBTnwUJyVOcusCnV7ieUEAuqdubJoqlEf1uYH4dyI xMgWZ+RoP8ev/vGldNwQlKb6YlMh+j2uTfZXgJzL/Epa8tM+zOHugZ1jX/SjDG12usXc7KxCT tPwMHbMINrXo8BjtKfF3pVQ6gMnFFZAOuAFKncE7SfZ8j4jNETJBV7gNUFyhzHXZjBumGQfg7 03lrL8g+wsnBSh95FrPd0F1t5JRIenN5nxCj9XvxJaLKts4+mDgRK3bkSc/IhUp1w4PupHvLN 4WQlXTcQ1pgFqGL7bZD8xWZUS2S6rxVJsUSxfRYmDL9gWkARB4b+QOnzSsUZ0zLlGfSUUUPnk z0SI7Ge0QSq4j70AN9QcghNTwu0cuhoASBBurGmE8e1rAqRTMyrEZoLtL6GOcJEeAPBIsR3fv 46slUBhhkQFdGz/+cxukryH1Vx+uVDT0Dj1zoYGLYgxheC1FHOQfxoGhp9MYnQasqldlT746J AIhK8Nk1yy8C36/jxz+A8TeC5rWnL3qf+U/swk4dv7K36tyS2mbRUL6eqKFxP6iHzceDKWNjJ 739imFugaTeMqVDbJaOX/09z9Hbfa8zF6k9WH/7+jR5oyvAcW3HCE9qICRlwrA9jnhiihC4WW QETp31GEjgn5yxEI58N0gox2kGmrMSjP/3hZLRFsH8ucXgEojHC0/pjR1ih53FuqIZWTJPgc8 wsWpt5RnaBZOnWBfwq7MUu16ovh8hwd15i6/Qw3LFEeVxXa6YATGHKpfh1sjczie5w97HSz9G J0+zXcVH8MXnmKNxnu3PErhv3iopxACdqPXo+P69Jl+zS6CXEavp7iUgDzYd7kUnsRZuxeeY/ s2HzrIz+I3uEm+HBf4kMRiHl4WMtjJDwtt3HGYWka3fg5M+CLVRtjTI3YrGRXuRE3QPFYiYAF U4Fdkw== Subject: Re: [musl] Question: Why vfprintf call twice printf_core? Am Sat, May 06, 2023 at 01:24:15PM +0800 schrieb 847567161: > snprintf(buf, sizeof(buf), "this is a more typical error message with de= tail: %s", "No such file or directory"); OK, that call is correct. It should not error out. >> First call to printf_core() checks to see if there are any major p= roblems with the format string > Maybe the second call can also checks the format error=EF=BC=9F > POSIX says that to the extent possible, all functions are supposed to either fail with no side effects or succeed with side effects. There are some functions that can fail with side effects, but we make some effort to minimize that. By testing the format string first, if it is broken, we can fail without side effects. If only the second call tested that, you would get a partial output before failure. Actually, in this case it was probably the other way around: Because POSIX requires that positional arguments work, which requires an extra pass over the format string, we got a side-effect free test for validity for free. >> if the string is using positional arguments (e.g. "%2$d"), also >> establishes the types of these arguments and writes them into an >> array. > I use above format string=EF=BC=8CI think it's a typical error mess= age, > I found the first printf_core do string traversal and cost some time > showed in perf. > > If we remove the first function call when we don't use ("%2$d"), is > there any problem=EF=BC=9FOr do you have some advice for impove the vfpr= intf > performance in common scenarios=EF=BC=9F vfprintf() can't know whether the format string contains positional arguments without passing over the format string. Which is what the first call does. In any case, yes, you can patch your copy of musl to remove the first call to printf_core(). You will no longer be able to use positional arguments, and you will get partial output on format string error, but if you can live with that, it should work. 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. 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); Of course, within ISO-C it gets more complicated, since strlcpy() and strlcat() are BSD functions. Ciao, Markus