This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [patch] Cleanup: don't call free(NULL) unnecessarily
- From: Andrew Hunter <ahh at google dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, libc-alpha at sourceware dot org
- Date: Tue, 5 Mar 2013 14:33:52 -0800
- Subject: Re: [patch] Cleanup: don't call free(NULL) unnecessarily
- References: <ye6qehft7j12.fsf@elbrus2.mtv.corp.google.com><m2fw09lc56.fsf@igel.home>
On Tue, Mar 5, 2013 at 2:23 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Paul Pluzhnikov <ppluzhnikov@google.com> writes:
>
>> Glibc free(NULL) also works in signal context, but end user could supply
>> his own malloc/free, which may not.
>
> I don't understand the reference to signal context. free (0) is trivial
> to implement, independent of context.
>
You are correct that it is not difficult to correctly implement
free(NULL). However, since free() in general is not
async-signal-safe, standards would totally allow a conformant free to,
say, take a lock before checking for a NULL input; if we then invoke
free(NULL) from signal context, everything can blow up.
With this patch, it is safe to call snprintf() (say) from signal
context so long as you avoid positional parameters, absurdly large
precision/width, or (sadly) any floating point formats (I'm uncertain
glancing at the code if there are floating-point formats where we'll
reliably choose alloca.)