On Tue, 2005-12-13 at 18:12 -0500, muppet wrote: > Gustavo J. A. M. Carneiro said: > > On Tue, 2005-12-13 at 15:40 -0500, muppet wrote: > >> throwing away the ability to fix bugs behind the scenes > > > > I meant this only for functions that are trivial; do you think there's > > any chance for anyone ever spot a bug in g_strdup? > > You already did --- the G_LIKELY() on the main if(). > > It should be marked with a compiler attribute that warns for ignoring the > return value (i think there's already patch for that, isn't there?). > > It could be changed to use g_memdup() instead of g_new() and memcpy(). > > It could use an early return on null input, or move the length variable into > the block where it is used. > > Also, what if GLib in the future begins to use a new heap manager which has a > custom, single-operation strdup function? With a real function, you could > work some magic to support that. With an inline, you're out of luck, old > binaries will continue to use the slow stuff. Those are optimisations, not bug fixes. Distributions end up recompiling all programs with the new headers, anyway, so that is only an issue for 3rd party binary programs, really. > Sorry if i seem to have exploded on a rhetorical question; this issue is > something of a hotbutton lately. It's ok; I enjoy good old fun flam^H^H^H discussions. This list sometimes seems rather dull, anyway; one has to try to spice it up a bit ;-) Regards. -- Gustavo J. A. M. Carneiro <gjc inescporto pt> <gustavo users sourceforge net> The universe is always one step beyond logic
Attachment:
signature.asc
Description: This is a digitally signed message part