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.0 required=5.0 tests=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 31181 invoked from network); 7 May 2023 01:17:55 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 May 2023 01:17:55 -0000 Received: (qmail 7288 invoked by uid 550); 7 May 2023 01:17:52 -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 7253 invoked from network); 7 May 2023 01:17:51 -0000 Date: Sat, 6 May 2023 21:17:38 -0400 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com Message-ID: <20230507011738.GJ4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Question: Why vfprintf call twice printf_core? On Sat, May 06, 2023 at 08:25:25AM +0200, Markus Wichmann wrote: > Am Sat, May 06, 2023 at 01:24:15PM +0800 schrieb 847567161: > > snprintf(buf, sizeof(buf), "this is a more typical error message with detail: %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 problems with the format string > > Maybe the second call can also checks the format error？ > > > > 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. This is all irrelevant because calling printf with an invalid format string has undefined behavior. There is no requirement at all on the implementation in this case. We could (and probably should) trap on it; the current behavior of bailing out when it's bad is just a consequence of how I implemnted the localization-form %n$ positional args. > >> 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，I think it's a typical error message, > > 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？Or do you have some advice for impove the vfprintf > > performance in common scenarios？ > > 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. Yes, I don't see any reason why this wouldn't work, but I also don't see any good reason it would help. If passing over the format string is taking a long time, maybe we should figure out why that's happening...? Rich