Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

[Eric Blake]

On 03/01/2018 10:20 AM, Alex Williamson wrote:
> On Thu,  1 Mar 2018 10:08:06 +0300
> Julia Suvorova via Qemu-devel <address@hidden> wrote:
>
> > basename(3) and dirname(3) modify their argument and may return
> > pointers to statically allocated memory which may be overwritten by
> > subsequent calls.
> > g_path_get_basename and g_path_get_dirname have no such issues, and
> > therefore more preferable.
>
> I think it's quite a bit arguable whether it's preferable, afaict there
> are no bugs fixed here.  The basic functions are being used correctly
> and are more conservative of memory usage than the glib variants.  In
> several cases below the basic functions seem far more efficient and we
> don't need to worry about freeing unnecessarily allocated memory, the
> diffstat seems to attest to this.  Is the inefficiency and possibility
> of leaking unintentionally allocated memory a statistical improvement
> over the claimed perils of these absolutely standard and well known
> functions?

The standard functions may be well-known, but as currently standardized 
are not very reliably useful in a multi-threaded program.  However, the 
standard WILL be improved in the future to require a saner standardized 
implementation (the proposed changes to the standard remove the ability 
for basename()/dirname() to return NULL, remove the allowance for 
non-thread-safe returns, and document more fully that the returned 
pointer will be back to the input string in all but a few corner cases 
which return const char *):

http://austingroupbugs.net/view.php?id=1064

> I know mine is a losing battle against glib, but the changelog might as
> well just say "Succumb to glib" because I fail to see that there's
> actually an improvement here.  If Paolo wants to take this,

One thing that the glib functions can do that the standardized version 
cannot do is handle drive letters on DOS-like systems (doesn't affect 
our builds on Linux or BSD, but may matter to mingw builds).  But you 
are right that the glib functions are more malloc-heavy than the (fixed) 
standardized functions, so it becomes a trade-off of how likely the libc 
functions are to comply with the tighter future standard version (that 
is actually somewhat useful) vs. the current standard version (that is a 
piece of trash because it has too many loopholes).

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org