<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:dblaikie@gmail.com" title="David Blaikie <dblaikie@gmail.com>"> <span class="fn">David Blaikie</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - The result of malloc(-1) is not as expected"
href="https://bugs.llvm.org/show_bug.cgi?id=52134">bug 52134</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>INVALID
</td>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - The result of malloc(-1) is not as expected"
href="https://bugs.llvm.org/show_bug.cgi?id=52134#c6">Comment # 6</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - The result of malloc(-1) is not as expected"
href="https://bugs.llvm.org/show_bug.cgi?id=52134">bug 52134</a>
from <span class="vcard"><a class="email" href="mailto:dblaikie@gmail.com" title="David Blaikie <dblaikie@gmail.com>"> <span class="fn">David Blaikie</span></a>
</span></b>
<pre>(In reply to Jolyon from <a href="show_bug.cgi?id=52134#c5">comment #5</a>)
<span class="quote">> (In reply to David Blaikie from <a href="show_bug.cgi?id=52134#c4">comment #4</a>)
> > (In reply to Jolyon from <a href="show_bug.cgi?id=52134#c3">comment #3</a>)
> > > 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?</span >
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.
<span class="quote">> And this optimization seems to mean that all mallocs are considered
> successful. </span >
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.
<span class="quote">> 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).</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>