From: Eric Blake <eblake@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>,
Chen Gang <gang.chen.5i5j@gmail.com>
Cc: aneesh.kumar@linux.vnet.ibm.com, aliguori@amazon.com,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf()
Date: Tue, 04 Feb 2014 06:09:26 -0700 [thread overview]
Message-ID: <52F0E686.4000206@redhat.com> (raw)
In-Reply-To: <20140204110631.GD5632@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]
On 02/04/2014 04:06 AM, Daniel P. Berrange wrote:
>>
>> v9fs need use "mkdir, remove ..." which have MAX_PATH limitation. So if
>> 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.
>
> I don't believe you are correct there. Those functions should
> return "errno == 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.
>
> Copying Eric who is involved the POSIX spec group to confirm.
>
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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2014-02-04 13:09 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-03 10:00 [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf() Chen Gang
2014-02-03 10:34 ` Daniel P. Berrange
2014-02-03 10:39 ` Chen Gang
2014-02-04 11:02 ` Chen Gang
2014-02-04 11:06 ` Daniel P. Berrange
2014-02-04 11:22 ` Chen Gang
2014-02-04 16:18 ` Aneesh Kumar K.V
2014-02-04 23:44 ` Chen Gang
2014-02-15 9:21 ` Chen Gang
2014-02-23 4:48 ` [Qemu-devel] [PATCH] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation Chen Gang
2014-02-23 5:18 ` Chen Gang
2014-02-24 9:22 ` Markus Armbruster
2014-02-24 11:16 ` Gang Chen
2014-02-24 12:52 ` Markus Armbruster
2014-02-27 23:35 ` Chen Gang
2014-03-01 17:33 ` [Qemu-devel] [PATCH 0/3] hw/9pfs: fix 3 issues which related with path string Chen Gang
2014-03-01 17:34 ` [Qemu-devel] [PATCH 1/3] hw/9pfs/virtio-9p-local.c: move v9fs_string_free() to below "err_out:" Chen Gang
2014-03-01 17:35 ` [Qemu-devel] [PATCH 2/3] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf() Chen Gang
2014-03-01 17:36 ` [Qemu-devel] [PATCH 3/3] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation Chen Gang
2014-03-03 8:34 ` Markus Armbruster
2014-03-03 10:51 ` Chen Gang
2014-03-03 16:22 ` Aneesh Kumar K.V
2014-03-03 19:29 ` Aneesh Kumar K.V
2014-03-04 0:27 ` Chen Gang
2014-03-03 8:34 ` [Qemu-devel] [PATCH 2/3] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf() Markus Armbruster
2014-03-03 10:54 ` Chen Gang
2014-03-03 14:42 ` Markus Armbruster
2014-03-04 0:38 ` Chen Gang
2014-03-03 15:33 ` Aneesh Kumar K.V
2014-03-03 15:33 ` Aneesh Kumar K.V
2014-03-03 15:29 ` [Qemu-devel] [PATCH 1/3] hw/9pfs/virtio-9p-local.c: move v9fs_string_free() to below "err_out:" Aneesh Kumar K.V
2014-03-04 0:11 ` Chen Gang
2014-03-03 17:43 ` [Qemu-devel] [PATCH 0/3] hw/9pfs: fix 3 issues which related with path string Eric Blake
2014-03-04 0:59 ` Chen Gang
2014-02-04 13:09 ` Eric Blake [this message]
2014-02-04 12:25 ` [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf() Markus Armbruster
2014-02-04 13:12 ` Eric Blake
2014-02-04 13:43 ` Chen Gang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52F0E686.4000206@redhat.com \
--to=eblake@redhat.com \
--cc=aliguori@amazon.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=berrange@redhat.com \
--cc=gang.chen.5i5j@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).