[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() inste
From: |
Eric Blake |
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
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
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf(), (continued)
- Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf(), Chen Gang, 2014/02/04
- Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf(), Aneesh Kumar K.V, 2014/02/04
- Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf(), Chen Gang, 2014/02/04
- Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf(), Chen Gang, 2014/02/15
- [Qemu-devel] [PATCH] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation, Chen Gang, 2014/02/22
- Re: [Qemu-devel] [PATCH] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation, Chen Gang, 2014/02/23
- Re: [Qemu-devel] [PATCH] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation, Markus Armbruster, 2014/02/24
- Re: [Qemu-devel] [PATCH] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation, Gang Chen, 2014/02/24
- Re: [Qemu-devel] [PATCH] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation, Markus Armbruster, 2014/02/24
- Re: [Qemu-devel] [PATCH] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation, Chen Gang, 2014/02/27
- Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf(),
Eric Blake <=
- Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf(), Markus Armbruster, 2014/02/04
- Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf(), Eric Blake, 2014/02/04
- Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf(), Chen Gang, 2014/02/04