[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-devel] [PATCH] migration: Replace strncpy() by

From: Paolo Bonzini
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] migration: Replace strncpy() by g_strlcpy()
Date: Tue, 21 Aug 2018 11:39:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 21/08/2018 08:03, Thomas Huth wrote:
>>> gcc is not necessarily wrong, as it CAN catch real erroneous uses of 
>>> strncpy().  It's just that 99% of the time, strncpy() is the WRONG 
>>> function to use, and so the remaining few cases where it actually does 
>>> what you want are so rare that you have to consult the manual anyways. 
>>> If nothing else, the gcc warning is making people avoid strncpy() even 
>>> where it is safe (which is not a bad thing, in my opinion, because the 
>>> contract of strncpy() is so counter-intuitive).
>> I am wondering if we should simply add a helper for these special cases
>> that zeroes the buffer and uses g_strlcpy(), instead of
>> ignoring/disabling the warning.
> Yes, a helper function with a proper comment about its purpose is likely
> the best way to go.

But why use g_strlcpy in the function (which has an off-by-one effect)?

Maybe it could be a qemu_strncpy that is the same as strncpy but returns
-ERANGE if the source is longer than the buffer that is passed in (but
not if it fits perfectly without a terminating NUL):

    int qemu_strncpy(const char *d, const char *s, int dsize)
        while (*s && dsize) {
            *d++ = *s++;
        /* It's okay if D is just past the end of the buffer,
         * and S is sitting on the terminating NUL.
        if (*s) {
            return -ERANGE;
        while (dsize) {
            *d++ = 0;
        return 0;

Then we have the problem of yet another incomplete transition, but at
least we could convert those that GCC complains about.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]