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