[LLVMdev] Reference Manual Clarifications 2

[Török Edwin]

Jon Sargeant wrote:
> Chris Lattner wrote:
>   
>> On Apr 19, 2008, at 3:27 PM, Jon Sargeant wrote:
>>     
>>>>> Regarding malloc and alloca, I realized that the size is unsigned,
>>>>> so a
>>>>> negative value for NumElements is impossible.  I suggest replacing  
>>>>> "it
>>>>> is the number of elements allocated" with "it is the UNSIGNED number
>>>>> of
>>>>> elements allocated".
>>>>>           
>>>> I'm not sure why this is more clear.
>>>>         
>>> The semantics of malloc and alloca depend on whether you interpret
>>> NumElements as a signed or unsigned 32-bit integer.  For example, if
>>> NumElements is 0xffffFFFF, should the instruction fail (because
>>> allocating a negative number of elements doesn't make sense), or  
>>> should
>>> the instruction allocate 2^32-1 elements?  I don't see any mention of
>>> whether NumElements is signed or unsigned in the documentation.
>>>       
>> How could an element count be treated as negative?  It doesn't make  
>> sense to allocate negative elements.
>>     
>
> True, but making NumElements unsigned just because it can never have a 
> negative value is not obvious.  I always use signed integers for 
> nonnegative counts for a couple of reasons.  First, I can assign -1 to 
> the count to indicate an invalid or unknown value.  Second, if I attempt 
> to allocate a negative count, I can print an assertion failure and abort 
> the program.  Had I interpreted the count as an unsigned value, the 
> program would attempt to allocate anywhere from 2 gigabytes to 4 
> gigabytes.  I'm not necessarily saying that NumElements should be 
> signed, only that the choice between signed and unsigned is not obvious.

In C malloc() takes an unsigned parameter.  For example on x86-32 Linux
I can allocate with malloc at most 4022034420 bytes (which would
otherwise be a signed value).
Since LLVM's malloc intrinsic can be used to replace a malloc call, I
think it should behave the same.

However alloca() would most certainly overflow the stack with such a
large allocation, and I think allocating >2G with alloca() can be
treated as undefined.

Best regards,
--Edwin