Re: [PATCH] SBuf c-string comparisons

On 04/16/2014 12:30 PM, Amos Jeffries wrote:
> On 17/04/2014 2:32 a.m., Alex Rousskov wrote:
>> On 04/16/2014 12:05 AM, Amos Jeffries wrote:
>>> 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?

Any reasonable/popular implementation selected by the developer. This is
a one-time check done by the developer, not an automated check done
during Squid build. Sorry I was not clear about that.

> That is a tricky "_if_" to code for.

I hope the above clarifies that no coding is necessary for this _if_.

> 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.

I do not think the above is possible.

>> 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.

See the cloning sketch in the previous email. To summarize, known
solutions are:

  1) a custom loop to properly limit SBuf iteration
  2) cloning to guarantee SBuf 0-termination

Since I expect (2) to be sometimes a lot slower than (1), I would go for
(1), especially if a quick check of a popular strncmp() implementation
does not expose some low-level optimizations that we would not be able
(or would not want) to duplicate in Squid.

Hope this clarifies,

Alex.
Received on Wed Apr 16 2014 - 19:23:21 MDT