RFR: SA: JDK-8189798: SA cleanup (original) (raw)
Jini George jini.george at oracle.com
Wed Nov 8 06:28:12 UTC 2017
- Previous message: RFR: SA: JDK-8189798: SA cleanup - part 1
- Next message: RFR: SA: JDK-8189798: SA cleanup - part 1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi David,
If we don't retain the cast, wouldn't that mean that we would be comparing 2 64 bit values in a 64 bit environment which would not be the intended comparison ?
Thanks, Jini.
On 11/8/2017 7:49 AM, David Holmes wrote:
Hi Jini,
On 11/7/17 4:16 AM, Jini George wrote: Thank you very much, Coleen, for the review. My answers inline:
On 11/2/2017 5:09 PM, coleen.phillimore at oracle.com wrote:
+ return (*(int *)&integervalue == *(int *)&value->integervalue); I don't think the (int) casts for integervalue are needed in these files. Can you remove them? [Jini] I think since integervalue is of type intptrt (which could be 8 or 4 bytes long depending on the data model), the removal of the casts could result in an incorrect comparison (mostly for the 64 bit environment). Let me know if you disagree. You're comparing two integervalue fields that are both intptrt. The important part you've overlooked is the comment preceding this: // [phh] compare only low addressed portions of intptrt slots - return (*(int *)&i == *(int *)&value->i); + return (*(int *)&integervalue == *(int *)&value->integervalue); For some we reason although intptrt we're only interested in the lower 32-bits. I have no idea why, nor why we would truncate the value when printing. David -----
- Previous message: RFR: SA: JDK-8189798: SA cleanup - part 1
- Next message: RFR: SA: JDK-8189798: SA cleanup - part 1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]