[LLVMdev] optimization assumes malloc return is non-null

[David Vandevoorde]

On May 1, 2008, at 12:47 PM, David Greene wrote:
> On Wednesday 30 April 2008 20:01, David Vandevoorde wrote:
>
>> 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.)
>
> You just contradicted yourself.  If an implementation can return  
> zero/null,
> then the optimizer can't assume the direction of the branch in this  
> case.  It
> has to allow the call to proceed and get the return value, unless it  
> knows
> about the specific implementation of malloc, which shouldn't be the  
> case
> for LLVM.



I don't see the contradiction.  Note that I'm only reasoning about the  
language; not specific implementations.

A valid implementation of malloc is "return 0;".  Therefore, a valid  
reduction of the original program is "int main() { return 0; }".   
However that is a reduction that posits an essentially useless malloc;  
so I'd be upset with my vendor if its C implementation behaved like  
that.  It's only a bit of trivia for language geeks.

(Much like a few years ago I frequently was told variations of "It  
isn't hard to write a 100% ISO-conforming C++ front end... in BASIC:
	10 PRINT "Out of resources"
	20 END
".)

Another valid implementation of malloc is one that actually returns a  
non-null pointer in this case, and for such an implementation, a valid  
reduction is "int main() { return 1; }".  That reduction is IMO not  
only valid, but also defensible and maybe desirable.  (And LLVM  
apparently does so.)

	Daveed