Re: glibc's snprintf bug causes printf(1) failure with MALLOC_PERTURB_ != 0

[Bruno Haible]

Hi Jim,

> > Is the MALLOC_PERTURB_ essential for the failure or not?
> 
> It appears to be essential, to ensure that the internal failure
> is manifested.

Given that
  - without MALLOC_PERTURB_, no SIGSEGV occurs,
  - early implementations of MALLOC_PERTURB_ were buggy [1],

we don't really know at this point if the bug is with snprintf() or with
MALLOC_PERTURB_ and malloc(). Is the problem reported as a glibc bug,
in the first place? Otherwise it won't get fixed.

> This suggests that all gnulib clients should use the replacements
> until the upstream/vendor implementations improve.
> Perhaps our standards are too high.

I agree: I'm reading that some distributions or packages use
MALLOC_PERTURB_ as a pre-release check. But they don't check for
MALLOC_PERTURB_ *and* low-memory conditions simultaneously. That
is a corner case that is not relevant in practice and not relevant for
pre-release checking. With this corner situation, you can find more
hidden bugs in packages, but I don't think it is worth a workaround in
gnulib.

Bruno

[1] http://sourceware.org/ml/libc-hacker/2005-09/msg00014.html