RFR: 8286378: Address possibly lossy conversions in java.base [v3]
ExE Boss
duke at openjdk.java.net
Fri May 13 04:44:38 UTC 2022
On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>>
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>>
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>>
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>
> Updated copyrights
> Fixed cast style to add a space after cast, (where consistent with file style)
> Improved code per review comments in PollSelectors.
src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:
> 126: // timed poll interrupted so need to adjust timeout
> 127: long adjust = System.nanoTime() - startTime;
> 128: to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);
This will now always assign a negative number to `to`.
--------------------------------------------------------------------------------
`=-` is not a compound assignment, it’s negation followed by a normal assignment.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8642
More information about the security-dev
mailing list