Re: [Qemu-devel] [PATCH 1/2] block: make bdrv_find_backing_image compare canonical filenames

[Eric Blake]

On 10/10/2012 12:29 PM, Jeff Cody wrote:

>> That's a LOT of stack space, which risks stack overflow, will mostly be
>> unused, and still doesn't work if you have super-deep hierarchies larger
>> than PATH_MAX.  Would you be better off using realpath(,NULL) for its
>> allocating semantics, and then free()ing the results?
>>
> 
> That is the main reason I changed it from being a recursive function, to
> an iterative one.
> 
> Do we know that realpath(,NULL) behaves the same on all platforms?

Gnulib lists the following platforms as mis-handling NULL:
Mac OS X 10.5, FreeBSD 6.4, OpenBSD 4.4, Solaris 10.

> 
> We had a thread back in April that touched on the use of realpath, and
> concerns were raised then that realpath(,NULL) was not necessarily safe
> across all OSes:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg01417.html

In fact, that message points out an even more insidious portability bug
in your algorithm: on Solaris 10, realpath("relative", buffer) leaves
buffer containing "relative" rather than an absolute name, but your
algorithm depends on matching absolute names.  I don't know if we port
qemu to Solaris 10, but it's worth considering my question back in that
thread - does glib provide us a more portable function for converting a
relative name into a canonical path that is guaranteed to work everywhere?

> 
> That said, if there is concern over the stack usage, to be safe I can
> manually g_malloc() each array.

g_malloc() would solve the stack size concern, but not the Solaris 10
relative name bug.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature