[jira] [Comment Edited] (NIFI-6672) Expression language plus operation doesn't check for overflow

["Alessandro D'Armiento (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-6672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16929937#comment-16929937 ] 

Alessandro D'Armiento edited comment on NIFI-6672 at 9/15/19 8:49 AM:
----------------------------------------------------------------------

I think this situation could be handled in several ways (This, of course, counts also for #NIFI-6673 and #NIFI-6674)

At the moment, the behavior is "let's not say anything" that IMO is the less reliable behavior possible.

Some possible upgrade could be: 
 * Evaluating `java.math.BigInteger`
 * Using `Math.addExact` to throw an `ArithmeticException` in case of overflow
 * Leaving the overflow issues as they are, but adding a `logger.warn` where a possible overflow is detected

 

Another source of confusion to be tackled IMO, is that EL `plus` (as well as minus, divide, multiply...) function allow both integral and decimal numbers, threating them either way at runtime:

```

if (subjectValue instanceof Double || plus instanceof Double)

{   result = subjectValue.doubleValue() + plus.doubleValue(); }

else

{   result = subjectValue.longValue() + plus.longValue(); }

```

This means that using `plus` to sum [Long.MAX_VALUE] `9223372036854775807L` and `100` will produce unmanaged overflow, while using it to sum `9223372036854775807L` and `100.0` will instead promote both values to Double, avoiding overflow but losing precision. 

Note also that causing overflow with two `Double` won't cause the output value to be rendered to `Double.POSITIVE_INFINITE` but will instead leave an empty `String` in the property. This could also be considered part of the bug IMO. 

 


was (Author: axelsync):
I think this situation could be handled in several ways (This, of course, counts also for #NIFI-6673 and #NIFI-6674)

At the moment, the behavior is "let's not say anything" that IMO is the less reliable behavior possible.

Some possible upgrade could be: 
 * Evaluating `java.math.BigInteger`
 * Using `Math.addExact` to throw an `ArithmeticException` in case of overflow
 * Leaving the overflow issues as they are, but adding a `logger.warn` where a possible overflow is detected

A source of confusion IMO is that EL `plus` (as well as minus, divide, multiply...) function allow both integral and decimal numbers, threating them either way at runtime:

```

if (subjectValue instanceof Double || plus instanceof Double){
  result = subjectValue.doubleValue() + plus.doubleValue();
} else {
  result = subjectValue.longValue() + plus.longValue();
}

```

This means that using `plus` to sum [Long.MAX_VALUE] `9223372036854775807L` and `100` will produce unmanaged overflow, while using it to sum `9223372036854775807L` and `100.0` will instead promote both values to Double, avoiding overflow but losing precision. 

Note also that causing overflow with two `Double` won't cause the output value to be rendered to `Double.POSITIVE_INFINITE` but will instead leave an empty `String` in the property. This could also be considered part of the bug IMO. 

 

> Expression language plus operation doesn't check for overflow
> -------------------------------------------------------------
>
>                 Key: NIFI-6672
>                 URL: https://issues.apache.org/jira/browse/NIFI-6672
>             Project: Apache NiFi
>          Issue Type: Bug
>    Affects Versions: 1.9.2
>            Reporter: Alessandro D'Armiento
>            Priority: Major
>         Attachments: image-2019-09-14-17-32-58-740.png
>
>
> To reproduce the bug, create a FF with an attribute equals to Long.MAX, then add 100 to that attribute in a following UpdateAttribute processor. The property will overflow to a negative number without throwing any exception
> !image-2019-09-14-17-32-58-740.png!



--
This message was sent by Atlassian Jira
(v8.3.2#803003)