[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
