From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13838 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Stdio resource usage Date: Thu, 21 Feb 2019 17:09:37 +0100 Message-ID: <20190221160937.GF19969@voyager> References: <20190220104901.GU21289@port70.net> <20190220154740.GD19969@voyager> <7816f8b4-644c-87e3-24c4-4ea2dd404584@adelielinux.org> <20190220191151.GE19969@voyager> <20190220192423.GD23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="231776"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13854-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 21 17:10:48 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gwqvw-000yCB-1G for gllmg-musl@m.gmane.org; Thu, 21 Feb 2019 17:10:48 +0100 Original-Received: (qmail 9568 invoked by uid 550); 21 Feb 2019 16:10:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9549 invoked from network); 21 Feb 2019 16:10:45 -0000 Content-Disposition: inline In-Reply-To: <20190220192423.GD23599@brightrain.aerifal.cx> X-Provags-ID: V03:K1:KhEfvJo6+WeZ5b5HYRZuZ5pqB1+CVXhmUI12nweRjon5+BWQTnY wcsu0mG7pCiPxkUH4UmPbULh84syspP65CyRjSzh7Dq/DNmzAlzWYTZjlHtBXZC6vqGOqpX BfriG2FBietSEjaAknrRVyvVAhCBMgzrI3Ci8FmvP6TNhbWBeQJabRfWW7kRUjPKE8uWoqy Mbrycl4ZmzIQ+lh4KisxA== X-UI-Out-Filterresults: notjunk:1;V03:K0:uT1VL0wa2lI=:9iXl7IMDHq0BZOW4jHsWfW vi/bG8LTFXy26HdEQnYtVgbGGoouPk6xenxDBhMAtV9LDJTINTgvL+CjbccWmlYeAUEY3K8EI BF6fsNa22F0qGkyXixsljCwBN7XJjIWQpzh0Tv3qzkEsTTwyzIxMQJmnvp20iqrKbw1huVWvm VMrNk7kn+6q9RXPSGZZcAJV4BBVgkg01ttbRRwHpjcBDdOIcfPAhvZFRnI77quwf9vgHCwgqR cdg8YC03qgPLSiOC2wQrQEklYKhwej4IXnDcP0y0zoPMBdRilFVcaAWIegnOGKJx/49fFKxZc 0i6AivLe93jXn8hTgG3jhPEo8qgBafc2h4LAl15L86eO0mn9chy2C5HGPPfcqsy5lchCoBwVv nJfut1adLID39iP3vWa+6dM4jcvLk+Mp1aPnEW3jMmbVP1Q3zBN2WOeirk+F0byzqVSHKdbX2 9eIa//BwLQB8n02MnuYEUxnfJvmCk91sfx7w6JAlUBSJXa8AwMrrNj16g8a/tttLJvACugKyV ukOi6QbVR9Sm43B5BfxcgD+Lab2D7H8ZraUIWpl8Ied5tpEG266Vheb7iBWejODsZ0dKyw3qq 72kxtC8zXFP9nyqmJSJOLrhhg5PisAnEt+qaxrb40wdSOrINqT47erDcF/JHJuHkpmEBfZKuO tZoBDHu7Jzmg0V0U+lUfICNtd4+rcGkrqQltWCwEJmWPAsmyHRCceLBouRa5lSC9f7ffE40Rm dXxUMXi9Ux9qhps4c4LWYYpZYa15pnk4Ny1/xVQ7/TSNxYrs4Mj3MiNxJJLgDxw2Mk2jMNqz Xref: news.gmane.org gmane.linux.lib.musl.general:13838 Archived-At: On Wed, Feb 20, 2019 at 02:24:23PM -0500, Rich Felker wrote: > For what it's worth, gcc has a -fconserve-stack that in principle > should avoid this problem, but I could never get it to do anything. If > it works now we should probably detect and add it to default CFLAGS. > > Rich Well, that also doesn't help since gcc is the compiler that *doesn't* exhibit the problem. clang does. And clang doesn't have an option to conserve stack (that I've seen). I am wondering what other possibilities exist to prevent the issue. If we won't change the algorithm, that only leaves exploring other possibilities for the memory allocation. So, what are our choices? - Heap allocation: But that can fail. Now, printf() is actually allowed to fail, but no-one expects it to. I would expect such behavior to be problematic at best. - Static allocation: Without synchronization this won't be thread-safe, with synchronization it won't be re-entrant. Now, as far as I could see, the printf() family is actually not required to be re-entrant (e.g. signal-safety(7) fails to list any of them), but I have seen sprintf() in signal handlers in the wild (well, exception handlers, really). - Thread-local static allocation: Which is always a hassle in libc, and does not take care of re-entrancy. It would only solve the thread-safety issue. - As-needed stack allocation (e.g. alloca()): This fails to prevent the worst case allocation, though it would make the average allocation more bearable. But I don't know if especially clever compilers like clang wouldn't optimize this stuff away, and we'd be back to square one. Any ideas left? Ciao, Markus