[LLVMdev] optimization assumes malloc return is non-null

[David Vandevoorde]

On Apr 30, 2008, at 8:47 PM, Jonathan S. Shapiro wrote:
> On Wed, 2008-04-30 at 18:17 -0500, David A. Greene wrote:
>> On Wednesday 30 April 2008 17:26, David Vandevoorde wrote:
>>
>>>>> ...malloc() is not specified to access a volatile
>>>>> object, modify an object, or modifying a file (directly or
>>>>> indirectly); i.e., it has no side effect from the language point  
>>>>> of
>>>>> view.
>>>>
>>>> Daveed:
>>>>
>>>> Good to know that I was looking at the correct section. I do not  
>>>> agree
>>>> that your interpretation follows the as-if rule, because I do not
>>>> agree
>>>> with your interpretation of the C library specification of  
>>>> malloc().
>>>
>>> Before I go on, let me state that this is not a contentious issue
>>> among WG14: There is no doubt that the intent of the standard is  
>>> that
>>> this be a valid optimization.
>>
>> Maybe I missed something, but aren't we all talking about the wrong  
>> thing
>> here?  It seems to me that this isn't about side effects, it's  
>> about the
>> return value of malloc.  Why can LLVM assume malloc will always  
>> return
>> non-zero?
>
> I hope that Daveed will correct me on this, but I think that the  
> theory
> is as follows:
>
>  Since the effect of malloc is not captured, the entire malloc can be
>  discarded. Any call to malloc that is discarded can be presumed
>  (arbitrarily) to succeed, and therefore to return non-null.


Correct.  It's an extreme form of garbage collection, I suppose ;-)

(In theory, it can also be assumed to fail -- because an  
implementation is allowed to make any call to malloc fail -- though  
that's probably not useful.)

	Daveed