Re: inlining glib functions (Was: public barrier functions)

["muppet" <scott asofyet org>]

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.


Sorry if i seem to have exploded on a rhetorical question; this issue is
something of a hotbutton lately.


-- 
muppet <scott at asofyet dot org>