From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAfky-0004sN-NG for qemu-devel@nongnu.org; Tue, 04 Feb 2014 08:09:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAfkr-00007y-2M for qemu-devel@nongnu.org; Tue, 04 Feb 2014 08:09:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAfkq-00007h-QH for qemu-devel@nongnu.org; Tue, 04 Feb 2014 08:09:32 -0500 Message-ID: <52F0E686.4000206@redhat.com> Date: Tue, 04 Feb 2014 06:09:26 -0700 From: Eric Blake MIME-Version: 1.0 References: <52EF68CA.9060604@gmail.com> <20140203103429.GB10408@redhat.com> <52EF71DC.3000309@gmail.com> <52F0C8BA.7020709@gmail.com> <20140204110631.GD5632@redhat.com> In-Reply-To: <20140204110631.GD5632@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ii95x6ujaC9HFdjnoUmcDIL3KVwvGRX0p" Subject: Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , Chen Gang Cc: aneesh.kumar@linux.vnet.ibm.com, aliguori@amazon.com, QEMU Developers This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ii95x6ujaC9HFdjnoUmcDIL3KVwvGRX0p Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/04/2014 04:06 AM, Daniel P. Berrange wrote: >> >> v9fs need use "mkdir, remove ..." which have MAX_PATH limitation. So i= f >> the combined path is longer than MAX_PATH, before it passes to "mkdir,= >> remove ...", it has to be truncated just like what rpath() has done. >=20 > I don't believe you are correct there. Those functions should > return "errno =3D=3D ENAMETOOLONG - pathname was too long". The > MAX_PATH constant is not even required to exist in POSIX, so > I would not expect the spec to mandate anything about MAX_PATH > in relation to those functions. >=20 > Copying Eric who is involved the POSIX spec group to confirm. >=20 Correct - POSIX intentionally allows GNU Hurd behavior which is no MAX_PATH. You can use openat() and friends to reduce the path length of an operation you are trying, and there, your limit becomes NAME_MAX (255 on many filesystems, but also a value that POSIX allows to be undefined). POSIX merely requires that the system be consistent - it cannot toggle between ENAMETOOLONG errors through one interface and acting on the name through another. > Even if they are limited, it is still better practice to use > dynamic allocation for this, over fixed length buffers IMHO. Agreed on two counts - dynamic allocation is essential on platforms where MAX_PATH is undefined and thus where path names can be constructed that occupy longer than a system page (because you do NOT want stack allocations longer than a page); and you WANT to try the system call because an ENAMETOOLONG from the system is definitive whereas giving up early because you only guess that it will be too long or because you used snprintf and truncated the string generally causes confusion. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Ii95x6ujaC9HFdjnoUmcDIL3KVwvGRX0p 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJS8OaGAAoJEKeha0olJ0NqUqkH/2Xfo9CJzTYm0IUB4hWOHImK D9KEgRp3X5U+hpJsqfBB+HPJ6xGCC3TT9f2mQY+qoIq2vyEBzRl3RfLYCvbJgGBl Ocl2YzlmQhnEBVJg/ndZ6iyKm7dkEAJ3X/I9L91jUKDf0zUIKEDF2AlqMMEJojP+ WbDMo7hblQ1spvIx3NlxhcahRKvHfJeghkOb/fl+zfm4ehUaKZ1bweKLJewWTzPb 2NmyPMJ639b4bcsSM5hLjfIa9tpcrHMnSoN0vO9xPfY0qYc4ptrNqZGQyCBry43a Yy7XUu53stG9KbKatIrJzw3gPQMBYEge40BpFYSdg7QBT+l0xsgHup9VWL4rTWk= =hkWt -----END PGP SIGNATURE----- --Ii95x6ujaC9HFdjnoUmcDIL3KVwvGRX0p--