mailing list of musl libc
 help / color / mirror / code / Atom feed
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


  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).