From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13839 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jens Gustedt Newsgroups: gmane.linux.lib.musl.general Subject: Re: Stdio resource usage Date: Thu, 21 Feb 2019 17:27:55 +0100 Organization: inria.fr Message-ID: <20190221172755.799b0b63@inria.fr> References: <20190220104901.GU21289@port70.net> <20190220154740.GD19969@voyager> <7816f8b4-644c-87e3-24c4-4ea2dd404584@adelielinux.org> <20190220191151.GE19969@voyager> <20190220192423.GD23599@brightrain.aerifal.cx> <20190221160937.GF19969@voyager> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/LJLMQu_EzpKc2D+DCgC1knd"; protocol="application/pgp-signature" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="43638"; mail-complaints-to="usenet@blaine.gmane.org" Cc: musl@lists.openwall.com Original-X-From: musl-return-13855-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 21 17:28:14 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 1gwrCm-000BCY-91 for gllmg-musl@m.gmane.org; Thu, 21 Feb 2019 17:28:12 +0100 Original-Received: (qmail 30395 invoked by uid 550); 21 Feb 2019 16:28:09 -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 30370 invoked from network); 21 Feb 2019 16:28:07 -0000 X-IronPort-AV: E=Sophos;i="5.58,395,1544482800"; d="scan'208";a="370375368" In-Reply-To: <20190221160937.GF19969@voyager> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ Xref: news.gmane.org gmane.linux.lib.musl.general:13839 Archived-At: --Sig_/LJLMQu_EzpKc2D+DCgC1knd Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, On Thu, 21 Feb 2019 17:09:37 +0100 Markus Wichmann wrote: > On Wed, Feb 20, 2019 at 02:24:23PM -0500, Rich Felker wrote: > So, what are our choices? >=20 > - 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. Perhaps the latter, but maybe with VLA? Unfortunately these techniques have no reliable error detection mechanism. For the static allocation strategy one could try to implement something like a "bounded" stack, that is two or three versions of the data in a array, protected by a lock and a counter, such that at least one level of signal handler could still use it. But this is probably a bit tedious to implement. Jens --=20 :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: --Sig_/LJLMQu_EzpKc2D+DCgC1knd Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCXG7RiwAKCRAP0+hp2tU3 4gjEAJ4vX3prLODAQHBJ4+sragmQYfdUEACfWRPIbEYL144GIAmlJGPqGjfU88k= =PgFN -----END PGP SIGNATURE----- --Sig_/LJLMQu_EzpKc2D+DCgC1knd--