Re: [PATCH] SBuf c-string comparisons

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.

Thank you,

Alex.
Received on Mon Apr 14 2014 - 14:56:22 MDT