[LLVMdev] optimization assumes malloc return is non-null

[Jonathan S. Shapiro]

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.

shap