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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
