|
Message-ID: <20190221160937.GF19969@voyager> Date: Thu, 21 Feb 2019 17:09:37 +0100 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: Re: Stdio resource usage 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.