RFR: 8145096: Undefined behaviour in HotSpot
aph at redhat.com
Fri Dec 11 09:58:07 UTC 2015
On 12/10/2015 09:44 PM, Kim Barrett wrote:
> To me, this seems to be trading one form of undefined behavior for
> another. Since there *is* a portable solution, which I understand is
> also well supported / optimized by compilers, I'd prefer that.
OK. I'm not convinced that a memcpy is into a signed int is really
more perfectly portable than a union, but I'm certain it will work for
the machines we care about. I'm not going to argue about it if that's
what you prefer: I just want the bugs to be fixed!
> Note that I would not like to see these java_xxx functions used as a
> general "solution" to overflow problems. Most cases of signed integer
> arithmetic overflow are actual bugs, and papering over them with these
> functions would be a mistake. I haven't reviewed them carefully, but
> the way these are being used in the various changes in the opto
> directory look appropriate, in order to match Java's defined behavior.
> But I wouldn't be surprised if there were other places (like the
> problem found in advancedThresholdPolicy.cpp) where I would not want
> these operations used. In fact, I'd like the comment describing these
> operations to say something along that line.
Okay, I'll do that. For the hash index computation it might make more
sense to do the whole thing unsigned.
More information about the hotspot-dev