Re: [PATCH] SBuf c-string comparisons

On 17/04/2014 2:32 a.m., Alex Rousskov wrote:
> On 04/16/2014 12:05 AM, Amos Jeffries wrote:
>> On 16/04/2014 5:07 a.m., Alex Rousskov wrote:
>>> If I am reading the code correctly, there is a new bug:
>>>
>>>> It also avoids the s[] access by using strlen(s) != byteCompareLen.
>>>
>>>> + if (byteCompareLen < n && strlen(s) != byteCompareLen)
>>>
>>> s is guaranteed to be 0-terminated when n == npos only. For other cases,
>>> we do not have such a guarantee and, hence, cannot use strlen(). Using
>>> strlen(s) when n is not npos may lead to s overreads.
>
>
>> I don't see any way around this without hand-crafing a full byte-by-byte
>> strncmp replacement.
>
> I am not against hand-crafting if it is really necessary -- we already
> hand-craft memCaseCmp IIRC. Personally, I would hand-craft _if_ system
> implementation of strncmp() is just a basic loop rather than some
> complicated, optimized low-level code. Otherwise, I would find a way to
> avoid strlen().

Which system? which architecture? which compiler? which library?

That is a tricky "_if_" to code for.

So...
 trying to find a way to determine the length of a c-string potentially
unterminated, without using strlen() or otherwise looping over it.
OR,
 trying to find out where the system strn*() function stopped.

I'm all ears for suggestions on that little gem.

>
> The following cloning approach also works, but I hope we do not have to
> pay such a high performance price here:
>
> SBuf clone(*this);
> return ... ? strncmp(clone.c_str(), s, n) : strncasecmp(...);
>
>
>> Which would appear to be overkill for this
>> transitional method (only needed until all I/O and globals/constants are
>> SBuf based).
>
> Since the hand-crafted implementation is simple, I do not consider it an
> overkill. And I am sure there is a way to avoid it if needed.

I would absolutely love to hear what that is.

Amos
Received on Wed Apr 16 2014 - 18:30:32 MDT