On Wed, Aug 08, 2018 at 11:47:34AM -0500, Nico Williams wrote:
> Yes. Would that snprintf() and vsnprintf() were async-signal-safe --
> they can be, and some implementations probably are, but they aren't
> required to be, then making ereport() safe would be easier.
So, I took a look at glibc's implementation for giggles. It uses
malloc() (and free()) only in three cases: a) when printing floating
point numbers with very large/small exponents, b) when formatting long
wide strings into multi-byte strings, c) when formatting specifiers have
width asterisks.
Assuming locales are not lazily loaded, I think that's probably all the
reasonable cases where vsnprintf() could call async-signal-unsafe
functions or do async-signal-unsafe things.
Considering that PostgreSQL already has async-signal-unsafe signal
handlers, might as well assume that vsnprintf() is async-signal-safe and
just format strings into alloca()'ed buffers or even into fixed-sized
automatic char arrays, and be done. Perhaps when a global volatile
sig_atomic_t is set denoting we're handling a signal, then use
vsnprintf() with a fixed-sized automatic buffer, otherwise malloc() one.
Nico
--