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? > > - 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 -- :: 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 ::