From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 3dbb5af5 for ; Mon, 3 Feb 2020 23:52:30 +0000 (UTC) Received: (qmail 7764 invoked by uid 550); 3 Feb 2020 23:52:28 -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 7746 invoked from network); 3 Feb 2020 23:52:28 -0000 Date: Tue, 4 Feb 2020 00:52:16 +0100 From: Szabolcs Nagy To: musl@lists.openwall.com, Simon Message-ID: <20200203235216.GB23985@port70.net> Mail-Followup-To: musl@lists.openwall.com, Simon References: <20200203215713.GS1663@brightrain.aerifal.cx> <20200203230534.GA23985@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200203230534.GA23985@port70.net> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [musl] Why does musl printf() use so much more stack than other implementations when printf()ing floating point numbers? * Szabolcs Nagy [2020-02-04 00:05:35 +0100]: > glibc uses variable amount of stack and it can be big, so > there is a check and then an alloca falls back to malloc. > (so yes it can probably fail with oom and not as-safe). > > the alloca threshold is 64k, i don't know if printf can > actually hit that (there are multiple allocas in printf, > some have smaller bounds). ok i was curious, it seems glibc allocates a temp buf of the size of the output assuming wchar_t, i.e. unbounded based on user input, and this allocations can fall back to malloc. otherwise glibc should allocate around the same stack as musl (i.e. 9K), so the glibc worst case stack usage is about 64K+9K and it may do an arbitrary large malloc instead of the large alloca. tested with sprintf(s, "%.99999Lf\n", 0x1p-16445L); on x86_64 glibc 2.29 with gdb, this does 3 mallocs of size 100031, 400012, 100004, so about 600K, and uses about 9K stack. (i dont know why there are 2 100k mallocs) musl mallocs 0K and uses < 9K stack.