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

[Chen Gang]

On 02/04/2014 09:12 PM, Eric Blake wrote:
> On 02/04/2014 05:25 AM, Markus Armbruster wrote:
> 
>> Second guessing when a pathname is too long for a system call is not a
>> good idea.  If it's too long, the system call will tell you.  As Dan
>> noted, PATH_MAX is *not* a hard limit.
>>
>>     {PATH_MAX}
>>         Maximum number of bytes the implementation will store as a
>>         pathname in a user-supplied buffer of unspecified size,
>>         including the terminating null character. Minimum number the
>>         implementation will accept as the maximum number of bytes in a
>>         pathname.
> 
> Linux allows unbelievably long absolute names.  Jim Meyering proved with
> coreutils that you can create an absolute name well over a megabyte in
> length.  The trick is that you have to access it via relative names
> where each relative name is PATH_MAX or less (that is, the Linux kernel
> refuses to operate on more than a page at a time when doing file name
> resolution), by using openat() and friends.  mkdirat() can create a
> directory with an absolute name longer than PATH_MAX, even if mkdir() can't.
> 

OK, thank all of you, what you said sound reasonable to me.  I don't
know why the original author/maintainer did not support 'unlimited'
path, so better to get original authors' opinion.

And can we split current discussion into 2 pieces:

 - fix sprintf() bug, can use snprintf() to fix it just like other
   places have done -- apply this patch (comments need be improved).

 - improve 9pfs features -- support 'unlimited' path internally.
   before do it, better to get original authors' response firstly.
   I guess, we need change quite a few areas and have a full test.



Thanks.
-- 
Chen Gang

Open, share and attitude like air, water and life which God blessed