On 02/05/2014 07:44 AM, Chen Gang wrote:
On 02/05/2014 12:18 AM, Aneesh Kumar K.V wrote:
That is a bug. The snprintf usage with PATH_MAX is to prevent buffer
overflow and not to truncate. I guess we should fix path handling
and propagate error correctly.
-aneesh
OK, thank you for your
On 02/03/2014 06:39 PM, Chen Gang wrote:
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote:
We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH,
so need use snprintf() instead of sprintf().
And also recommend to use
On Tue, Feb 04, 2014 at 07:02:18PM +0800, Chen Gang wrote:
On 02/03/2014 06:39 PM, Chen Gang wrote:
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote:
We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH,
so need use
On 02/04/2014 07:06 PM, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 07:02:18PM +0800, Chen Gang wrote:
On 02/03/2014 06:39 PM, Chen Gang wrote:
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote:
We can not assume 'path' +
Chen Gang gang.chen.5...@gmail.com writes:
On 02/03/2014 06:39 PM, Chen Gang wrote:
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote:
We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH,
so need use snprintf() instead
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
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
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}
Chen Gang gang.chen.5...@gmail.com writes:
On 02/04/2014 07:06 PM, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 07:02:18PM +0800, Chen Gang wrote:
On 02/03/2014 06:39 PM, Chen Gang wrote:
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen
On 02/05/2014 12:18 AM, Aneesh Kumar K.V wrote:
Chen Gang gang.chen.5...@gmail.com writes:
On 02/04/2014 07:06 PM, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 07:02:18PM +0800, Chen Gang wrote:
On 02/03/2014 06:39 PM, Chen Gang wrote:
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote:
We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH,
so need use snprintf() instead of sprintf().
And also recommend to use ARRAY_SIZE instead of hard code macro for an
array size in snprintf().
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
hw/9pfs/virtio-9p-local.c | 9
On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote:
We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH,
so need use snprintf() instead of sprintf().
And also recommend to use ARRAY_SIZE instead of hard code macro for an
array size in snprintf().
In the event that
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote:
We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH,
so need use snprintf() instead of sprintf().
And also recommend to use ARRAY_SIZE instead of hard code macro for an
13 matches
Mail list logo
