Bruno Haible <[EMAIL PROTECTED]> wrote: >> > 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.
Yes, of course it is reported. ;-) The RHEL bugzilla I mentioned initially is filed against glibc. Or perhaps you meant glibc's own bugzilla? >> 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. Not surprising. Doing both is tricky. > 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. If it turns out just to be a bug in the implementation of MALLOC_PERTURB_, then it's not worth the effort to make gnulib work around it. However, if it's a real error in glibc's snprintf (as I suspect) -- i.e., the MALLOC_PERTURB_=N (N!=0) setting merely ensures a consistently reproducible failure, whereas the bug can be triggered with MALLOC_PERTURB_=0, but under some other circumstances -- *then* it requires a work-around.
