This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #12847] dprintf/vdprintf can cause fork to fail (child process crash)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, OndÅej BÃlka <neleai at seznam dot cz>, <libc-alpha at sourceware dot org>
- Date: Wed, 25 Sep 2013 19:38:40 +0000
- Subject: Re: [PATCH][BZ #12847] dprintf/vdprintf can cause fork to fail (child process crash)
- Authentication-results: sourceware.org; auth=none
- References: <20130921191346 dot GA9202 at domone dot kolej dot mff dot cuni dot cz> <20130921194515 dot GF20515 at brightrain dot aerifal dot cx> <20130921202326 dot GA9893 at domone dot kolej dot mff dot cuni dot cz> <20130921214227 dot GG20515 at brightrain dot aerifal dot cx> <20130924210329 dot F00F22C097 at topped-with-meat dot com> <20130924213453 dot GO20515 at brightrain dot aerifal dot cx> <20130925180327 dot 0351F2C097 at topped-with-meat dot com>
On Wed, 25 Sep 2013, Roland McGrath wrote:
> > If so, since dprintf is not required to be AS-safe,
> > should it just be filed like a wishlist item?
>
> Sure. Though, as the sole inventor of dprintf many years before it was
> standardized, I can say authoritatively that it was always the intent that
> it not have any more entanglements (i.e. potential failure modes) than
> stack use and calling write. (That was never exactly true in the face of
> user-defined printf extensions, but close enough.)
There are plenty of cases where the underlying printf code uses malloc if
it needs an allocation too large for alloca (and the cut-off, or how such
allocations relate to the arguments passed to dprintf, is not as far as I
know considered a public interface to glibc).
--
Joseph S. Myers
joseph@codesourcery.com