On 03/01/2018 10:20 AM, Alex Williamson wrote:
On Thu,  1 Mar 2018 10:08:06 +0300
Julia Suvorova via Qemu-devel <qemu-devel@nongnu.org> 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

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 *):


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

Reply via email to