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
