Define strnlen when it is not in libc

[Chi-Hua Chen via llvm-commits]

Duncan,

On Mon, Nov 28, 2016 at 1:56 PM, Duncan P. N. Exon Smith
<dexonsmith at apple.com> wrote:
>> On 2016-Nov-28, at 10:55, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>>> On 2016-Nov-24, at 11:10, Joerg Sonnenberger via llvm-commits <llvm-commits at lists.llvm.org> wrote:
>>>
>>> On Thu, Nov 24, 2016 at 02:06:55PM -0500, Chi-Hua Chen via llvm-commits wrote:
>>>> Some older platforms, e.g. Mac 10.6.8, do not have strnlen. Define one
>>>> in Support when necessary.
>>>
>>> Personally, I'd prefer to just avoid it in first place. It is not really
>>> much simpler than just using memchr.
>>
>> `StringRef(...).find('\0')` seems cleaner.
>
> But I'm fine with the original patch as well, since it avoids people introducing more uses of strnlen in the future...

I don't think either patch (one defines strnlen, the other using
memchr -- I haven't submitted this one yet) would prevent people from
introducing more uses of strnlen.

I have a question about the change in HeaderMap.cpp that introduced
the first though: why is '&& Data[Len - 1]' necessary?
https://github.com/llvm-mirror/clang/commit/839cd13b65d802f06276ff88d234419c38a44199#diff-860876c157b9f2ff75bce0d006cadc63

> assuming we actually support building on 10.6?  (There weren't any buildbot failures...)

I don't see any OS requirements for building llvm/clang. We did have
to install a modified version of gcc on our old Mac.

>
>>
>>>
>>> Joerg
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>