[llvm-bugs] [Bug 52134] The result of malloc(-1) is not as expected

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=52134

David Blaikie <dblaikie at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #6 from David Blaikie <dblaikie at gmail.com> ---
(In reply to Jolyon from comment #5)
> (In reply to David Blaikie from comment #4)
> > (In reply to Jolyon from comment #3)
> > > What I care about is that the results of O0 and O2 are different. 
> > 
> > The result of a program like this could be different between executions when
> > compiled at the same optimization level (different memory availability, etc)
> > - so it doesn't seem too surprising, yeah?
> > 
> > > So This is most likely an undefined behavior? But I haven't find related UB?
> > 
> > I don't think it's undefined behavior - it's within the space of acceptable
> > behaviors for the program. (imagine a smaller sized allocation - sometimes
> > it might succeed, when there's memory available, and sometimes it might fail
> > when there isn't memory available - so returning null or non-null from a
> > malloc call are both valid results)
> 
> I think I agree with you. Allocating a block of memory can fail and succeed,
> but the result of allocating memory depends on the result of malloc, right?

This statement gets a bit tricky. What does it mean to the specification/user
to say "the result of allocating memory depends on the result of malloc" - how
could a user observe that? If the user had written their own implementation of
malloc and observed that that implementation was/wasn't called, or its result
was/wasn't propagated? But the C and C++ specs don't offer a way to replace
malloc in this sense - malloc is part of the implementation.

eg: it'd be valid for there never to be a "malloc" function (well, ignoring
taking the address of malloc for a minute) and for an implementation to emit
code inline that handles allocation - and to emit the code clang emits here
that assumes success when the allocation isn't otherwise used.

> And this optimization seems to mean that all mallocs are considered
> successful. 

If the result is only tested for truth, yes. If the result is otherwise used -
dereferenced, printed out as you noted, etc, then it may not succeed.

> If we add use of p and the result is 0(eg, add fprintf(stderr,
> "FAIL malloc(-1) = %p\n", p); here). 
> It's weird from a programmer's point of view, but I agree with the principle
> here(If we have a malloc call which is only used in any amount of
> comparisons to null and free calls, delete the calls and replace the
> comparisons with true or false as appropriate).

Yep - that's my understanding. Resolving as "working as intended" - but happy
for more discussion or if someone's got pointers to/other arguments that this
shouldn't be considered a valid optimization, happy to discuss further.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20211012/04ce2c0b/attachment.html>