Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf()

[Eric Blake]

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