|
From: Adam G. <ar...@cy...> - 2003-04-25 16:22:57
Attachments:
t
|
The new memcheck provided versions of strncpy() and strncat() will read one byte past the maximum number 'n' bytes in 'src'. If this byte is not initialised, you get a spurious error report from valgrind. I can't _actually_ find a spec anywhere which says what is supposed to happen if the source string is not nul terminated, but I'm pretty sure it's a bug. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |
|
From: Nicholas N. <nj...@ca...> - 2003-04-25 16:29:00
|
On Fri, 25 Apr 2003, Adam Gundy wrote: > The new memcheck provided versions of strncpy() and strncat() will > read one byte past the maximum number 'n' bytes in 'src'. If this byte is not > initialised, you get a spurious error report from valgrind. > > I can't _actually_ find a spec anywhere which says what is supposed to > happen if the source string is not nul terminated, but I'm pretty sure it's a > bug. Ah, good catch. I knew I wouldn't be able to write them bug-free. Lucky Valgrind can check at least some parts of itself :) I will commit, thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-25 16:43:34
|
On Fri, 25 Apr 2003, Nicholas Nethercote wrote:
> > The new memcheck provided versions of strncpy() and strncat() will
> > read one byte past the maximum number 'n' bytes in 'src'. If this byte is not
> > initialised, you get a spurious error report from valgrind.
> >
> > I can't _actually_ find a spec anywhere which says what is supposed to
> > happen if the source string is not nul terminated, but I'm pretty sure it's a
> > bug.
>
> Ah, good catch. I knew I wouldn't be able to write them bug-free. Lucky
> Valgrind can check at least some parts of itself :)
>
> I will commit, thanks.
Actually, before I do... the offending line looked like this:
while (*src && m++ < n) *dst++ = *src++;
you substituted this:
while (m++ < n && *src) *dst++ = *src++;
but this doesn't work for strncpy() if the nth char is '\0', because m is
incremented when it shouldn't be. See memcheck/tests/overlap for an
example.
I suggest this instead:
while (m < n && *src) { m++; *dst++ = *src++; }
What do you think? Your version of strncat() is ok, though. I think;
these things are subtle...
N
|
|
From: Adam G. <ar...@cy...> - 2003-04-25 16:56:12
|
At 17:43 25/04/03 +0100, Nicholas Nethercote wrote:
>On Fri, 25 Apr 2003, Nicholas Nethercote wrote:
>
>> > The new memcheck provided versions of strncpy() and strncat() will
>> > read one byte past the maximum number 'n' bytes in 'src'. If this byte is not
>> > initialised, you get a spurious error report from valgrind.
>> >
>> > I can't _actually_ find a spec anywhere which says what is supposed to
>> > happen if the source string is not nul terminated, but I'm pretty sure it's a
>> > bug.
>>
>> Ah, good catch. I knew I wouldn't be able to write them bug-free. Lucky
>> Valgrind can check at least some parts of itself :)
>>
>> I will commit, thanks.
>
>Actually, before I do... the offending line looked like this:
>
> while (*src && m++ < n) *dst++ = *src++;
>
>you substituted this:
>
> while (m++ < n && *src) *dst++ = *src++;
>
>but this doesn't work for strncpy() if the nth char is '\0', because m is
>incremented when it shouldn't be. See memcheck/tests/overlap for an
>example.
>
>I suggest this instead:
>
> while (m < n && *src) { m++; *dst++ = *src++; }
>
>What do you think? Your version of strncat() is ok, though. I think;
>these things are subtle...
personally I hate using '++' and '--' as part of a condition - you're never
sure when it's going to do the increment/decrement. your version is much
better.
Seeya,
Adam
--
Real Programmers don't comment their code. If it was hard to write,
it should be hard to read, and even harder to modify.
These are all my own opinions.
|