From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TM17G-0002XL-2t for qemu-devel@nongnu.org; Wed, 10 Oct 2012 14:34:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TM176-0004pJ-G9 for qemu-devel@nongnu.org; Wed, 10 Oct 2012 14:34:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50701) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TM176-0004p9-7W for qemu-devel@nongnu.org; Wed, 10 Oct 2012 14:34:36 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9AIYZA9021964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Oct 2012 14:34:35 -0400 Message-ID: <5075BFBA.8020902@redhat.com> Date: Wed, 10 Oct 2012 12:34:34 -0600 From: Eric Blake MIME-Version: 1.0 References: <37ca1a150224c144f9329fc8408f78c388f50a02.1349848348.git.jcody@redhat.com> <5075BADF.2070402@redhat.com> <5075BE97.1070407@redhat.com> In-Reply-To: <5075BE97.1070407@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8E387E427EC0B812ED06B800" Subject: Re: [Qemu-devel] [PATCH 1/2] block: make bdrv_find_backing_image compare canonical filenames List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jcody@redhat.com Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8E387E427EC0B812ED06B800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/10/2012 12:29 PM, Jeff Cody wrote: >> That's a LOT of stack space, which risks stack overflow, will mostly b= e >> unused, and still doesn't work if you have super-deep hierarchies larg= er >> than PATH_MAX. Would you be better off using realpath(,NULL) for its >> allocating semantics, and then free()ing the results? >> >=20 > That is the main reason I changed it from being a recursive function, t= o > an iterative one. >=20 > 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. >=20 > 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: >=20 > 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= ? >=20 > 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. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig8E387E427EC0B812ED06B800 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQdb+6AAoJEKeha0olJ0NqRtgIAIatryc9dR3W0M/mr3VVjrPo Pz6u7uQShPIkf1+wvz9AMPC1p3TTB9GCpi5iiiuaDeofu9Jbw3uGsf7srTh2BxBz ULdSk61dkSx1MjGR+JS/YGDrQcyQJrnuzKuewXGW1smkyaYKTO0U1J4sstllaYvB JiVNpt2J0LKBcnq+iPO9ZK9aLHhQCYXm8ZTwTP/dvg9xnj1zXuWpKl/YgE9KJklG APNOZP6WudmB2jxu2xIN10UOoffASZTL0dOpZnzKGY+8ebqXYt/Pm7caf+8l8/dg W+sIY7pXcBWMK4vS8c64/CmQ7nmZQdeWQEvQPu3Z911PW8QEctxuJlHjzDWzkJA= =J3rC -----END PGP SIGNATURE----- --------------enig8E387E427EC0B812ED06B800--