Re: [PATCH] SBuf c-string comparisons

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 15 Apr 2014 05:04:07 +1200

On 15/04/2014 2:56 a.m., Alex Rousskov wrote:
> On 04/14/2014 04:49 AM, Amos Jeffries wrote:
>> I've added a unit test to catch the rare \0 mid-string case I spoke of:
>> * SBuf("foo\0test").compare("foo", 9);
>>
>> It works fine up to the point N(4) > strlen("foo"). After that point our
>> function returns 1 to indicate that the SBuf is a longer string, whereas
>> strncmp/strncasecmp return 0 up to infinity.
>
> Yes, this is related to the large-n handling bug I keep talking about.
> IMO, this must be fixed as previously discussed: C-string API should not
> look past the first null character.
>
>
>> The code as presented earlier copes with the weirdness fine.
>
>
> AFAICT, the latest posted patch accesses non-existent c-string bytes
> under certain conditions (large n, large SBuf with trailing null
> characters, short s matching the c-string in SBuf). Do you agree? If you
> do agree, please post a fixed patch. If not, I would have to spend time
> writing a test case to prove my point against the last patch posted.

I agree.

Attached patch implements what we agreed on in IRC.

It produces two wrong return value states. Marked with "BUG 1" and "BUG
2" in the patch.

Amos

Received on Mon Apr 14 2014 - 17:04:26 MDT

This archive was generated by hypermail 2.2.0 : Mon Apr 14 2014 - 12:00:12 MDT