[llvm-dev] Is it time to allow StringRef to be constructed from nullptr?

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 28 07:42:06 PDT 2016



On 09/27/2016 10:05 PM, Chris Lattner via llvm-dev wrote:
>
>> On Sep 27, 2016, at 9:41 AM, Mehdi Amini <mehdi.amini at apple.com 
>> <mailto:mehdi.amini at apple.com>> wrote:
>>
>>
>>> On Sep 25, 2016, at 5:40 PM, Chris Lattner <clattner at apple.com 
>>> <mailto:clattner at apple.com>> wrote:
>>>
>>> The pointer could only be null if the length is zero.  If the length 
>>> is zero, you shouldn't be loading it.
>>
>> I was thinking about functions that takes a non-null pointer. For 
>> example, assuming you have:
>>
>> extern void *my_memcpy (void *dest, const void *src, size_t 
>> len) __attribute__((nonnull (1, 2)));
>>
>> You can just be calling it with any StringRef without a null pointer 
>> check.
>>
>> That said it is just a thought I had, I don’t have any data or actual 
>> example to back this up.
>
> Yeah, I’m not sure where this comes up, and whether memcpy should take 
> null when the length is zero is also a highly contentious thing that 
> flares up in debates periodically.
One place that might be relevant is the existing special handling in 
StringRef around memcmp to avoid undefined behavior due to null 
pointers.  It hints that we've already hit this issue once.
>
>>
>>
>>>  Defaulting to null instead of "" is also a microoptimization.
>>
>> You mean: because initializing to 0 is faster than a constant?
>
> Yes, 0 is a “load immediate”, initializing to “” requires 
> materializing the address of a global.
>
> -Chris
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160928/770aca1d/attachment.html>


More information about the llvm-dev mailing list