|
From: | Eric Blake |
Subject: | Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename |
Date: | Fri, 2 Mar 2018 09:20:03 -0600 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |