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