<div dir="ltr">Yeah, those sound like exactly what we want. Helping people find UB is good, but optimizing assuming we've fixed all of the UB isn't something we can do. Our bugs end up being rather permanent so we need to be defensive.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 11, 2015 at 1:18 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Aug 11, 2015 at 4:10 PM, Dan Albert <<a href="mailto:danalbert@google.com">danalbert@google.com</a>> wrote:<br>
>> Would you be opposed to annotations that tell the programmer they have<br>
>> UB in their code, but *do not* effect the code generation?<br>
><br>
><br>
> Not on our end. This would be great.<br>
<br>
</span>I ask because the new nullability attributes do not affect codegen<br>
(that I'm aware of), and so they might be a reasonable tradeoff<br>
between warning users that they've done something with UB, without<br>
triggering aggressive optimizations, if we didn't want to have some<br>
sort of flag for this.<br>
<br>
That being said, the user's code does have UB if it passes in a null<br>
pointer for these APIs and relying on the compiler to not optimize<br>
that is asking for trouble. Warning them about the UB is very<br>
important. Not optimizing on the UB is far less so, IMO.<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> On Tue, Aug 11, 2015 at 12:56 PM, Aaron Ballman via cfe-commits<br>
> <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
>><br>
>> On Tue, Aug 11, 2015 at 3:32 PM, Joerg Sonnenberger via cfe-commits<br>
>> <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
>> > joerg added a comment.<br>
>> ><br>
>> > No, it doesn't. It tells the compiler that it is free to make such<br>
>> > assumptions. Take a step back from the standard. Can you think of any<br>
>> > reasonable and efficient implementation of memcpy and friends, which fails<br>
>> > for size 0? Adding the annotations (whether here or in string.h) effectively<br>
>> > changes the behavior of the program. It is behavior people have been<br>
>> > expecting for two decades, even when C90 said something else. This is<br>
>> > completely different from the warning annotations. I'm just waiting for some<br>
>> > of the bigger projects like PostgreSQL to start getting annoyed enough to<br>
>> > introduce sane_memcpy for this.<br>
>> > I can't speak for Linux distributions using glibc, but I find this kind<br>
>> > of smoking gun completely unacceptable to force unconditionally on everyone.<br>
>><br>
>> Would you be opposed to annotations that tell the programmer they have<br>
>> UB in their code, but *do not* effect the code generation?<br>
>><br>
>> ~Aaron<br>
>> _______________________________________________<br>
>> cfe-commits mailing list<br>
>> <a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>