From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S13tu-0000CS-GD for qemu-devel@nongnu.org; Fri, 24 Feb 2012 17:46:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S13ts-0002L8-Sy for qemu-devel@nongnu.org; Fri, 24 Feb 2012 17:46:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8122) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S13ts-0002Kz-Ke for qemu-devel@nongnu.org; Fri, 24 Feb 2012 17:46:04 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1OMk3kD012270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 Feb 2012 17:46:03 -0500 Message-ID: <4F48132A.40209@redhat.com> Date: Fri, 24 Feb 2012 15:46:02 -0700 From: Eric Blake MIME-Version: 1.0 References: <1329930815-7995-1-git-send-email-fsimonce@redhat.com> <1330102144-14491-2-git-send-email-fsimonce@redhat.com> <20120224170143.78f55d3e@doriath.home> <4F47E7A1.1020200@redhat.com> <20120224182655.7594983c@doriath.home> In-Reply-To: <20120224182655.7594983c@doriath.home> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE1434ACF8DDDF3DAE57C42BE" Subject: Re: [Qemu-devel] [PATCH 2/2 v2] Add the blockdev-reopen and blockdev-migrate commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: kwolf@redhat.com, mtosatti@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, Federico Simoncelli , pbonzini@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE1434ACF8DDDF3DAE57C42BE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/24/2012 01:26 PM, Luiz Capitulino wrote: > On Fri, 24 Feb 2012 12:40:17 -0700 > Eric Blake wrote: >=20 >> On 02/24/2012 12:01 PM, Luiz Capitulino wrote: >> >>>> + BlockDriver *drv; >>>> + int i, j, escape; >>>> + char new_filename[2048], *filename; >>> >>> I'd use PATH_MAX for new_filename's size. >> >> PATH_MAX need not be defined (and on Hurd, it intentionally is not >> defined); or might be so huge as to be useless. >=20 > Aren't those extreme cases? PATH_MAX is a standard define and is used i= n > QEMU in several places. If it's not good here, it shouldn't be good any= where. PATH_MAX is specifically declared in POSIX to be defined if there is a limit, or undefined if there is no limit. There is no limit in GNU Hurd, so PATH_MAX is undefined there, and you will get a compile error (then again, no one has ported qemu to Hurd). Here's what gnulib has recommended: https://lists.gnu.org/archive/html/bug-gnulib/2011-06/msg00328.html > A package like coreutils can also do > #ifndef PATH_MAX > # define PATH_MAX 8192 > #endif > in its system.h. >=20 > Looking at both uses of PATH_MAX in coreutils (src/pwd.c:88 and > src/remove.c:186) the value of PATH_MAX is capped by 8192 or 16384 anyw= ay. > So, on systems like GNU/Hurd, where filenames can have arbitrary size, = you > are calling pathconf for no real purpose. >=20 > To me, this confirms that a generic pathmax.h (like the one in gnulib) > should only define PATH_MAX when it makes sense - like POSIX says -, > and that the handling of the GNU/Hurd case should be done on a case-by-= case > basis: > - Either a package-wide handling, or a per-file handling. > - Either a fallback value of 8192, or a fallback value of > pathconf ("/", _PC_PATH_MAX), or just a #ifdef test. Other mails in that thread are also an interesting read. In short, use of PATH_MAX should only ever be used to optimize routines to the common case; in which case, you can pick your own cap for PATH_MAX if the implementation did not provide one or reduce the implementation's 8k PATH_MAX down to something like 2048 that you can safely fit on the stack for the common case before malloc'ing for the larger strings. But using it as a bounds to a statically-sized object is a recipe for artificially limiting software; if you are okay with introducing that artificial limit, then go for it; but if you want to be truly portable, it is best to never use PATH_MAX as an array bounds, and to write fallback code paths to handle the cases where user input exceeds PATH_MAX but can still be handled without error by the system you are running on. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigE1434ACF8DDDF3DAE57C42BE 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://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPSBMqAAoJEKeha0olJ0NqvYAH/RtoAN8d+D02PD3RbiQQfgpr L1uW1iFGVUtnPBND5AZMj/4TuRiGtSkfVKyxajaljDtQhlTdmuG68dMa9U20rZWq tdF3FzFlScDohxSYSt2C/G8Y9d2hQMScIuSB97VtU9YKxZsduA91obYB1Vf+/85r UQSaZz/jvragVgFjaO88O1Wg76ul2E+VScPWM19aAIOkxxBP/v47DTzapYlsHSPY 2wEuE8rVuAXI7Vqgrahxq8VtWFRDGExhdPC/2S8LWQ1TL7nHwXoSNu0hj9/S4Ye3 v6hFcsrBXu9oHfwp6VxKvuESDUQk1bLd0tXTQTBYkUrMKdQtbZ23dLXZfFxbmcI= =VANl -----END PGP SIGNATURE----- --------------enigE1434ACF8DDDF3DAE57C42BE--