From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: Stdio resource usage
Date: Thu, 21 Feb 2019 17:09:37 +0100 [thread overview]
Message-ID: <20190221160937.GF19969@voyager> (raw)
In-Reply-To: <20190220192423.GD23599@brightrain.aerifal.cx>
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
next prev parent reply other threads:[~2019-02-21 16:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-19 23:34 Nick Bray
2019-02-20 2:43 ` Rich Felker
2019-02-20 10:49 ` Szabolcs Nagy
2019-02-20 15:47 ` Markus Wichmann
2019-02-20 16:37 ` Szabolcs Nagy
2019-02-20 17:13 ` Rich Felker
2019-02-20 18:34 ` A. Wilcox
2019-02-20 19:11 ` Markus Wichmann
2019-02-20 19:24 ` Rich Felker
2019-02-21 16:09 ` Markus Wichmann [this message]
2019-02-21 16:27 ` Jens Gustedt
2019-02-21 17:02 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190221160937.GF19969@voyager \
--to=nullplan@gmx.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).