[
https://issues.apache.org/jira/browse/JOHNZON-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16736365#comment-16736365
]
Anders Rundgren commented on JOHNZON-177:
-----------------------------------------
Indeed:
https://github.com/eclipse-ee4j/jsonb-api/issues/112
Anders
> Deserialization of numbers can produce overflows and underflows
> ---------------------------------------------------------------
>
> Key: JOHNZON-177
> URL: https://issues.apache.org/jira/browse/JOHNZON-177
> Project: Johnzon
> Issue Type: Bug
> Affects Versions: 1.1.8
> Reporter: Markus Bruckner
> Assignee: Mark Struberg
> Priority: Minor
> Fix For: 1.1.11
>
>
> Given the following json:
>
> {code:java}
> {
> "value": 2147483648
> }{code}
> and the following dto:
>
> {code:java}
> public class IntContainer {
> private int value;
> public void setValue(int value) { this.value = value; }
> public int getValue() { return value; }
> }{code}
> When I try to parse the json in the dto, the value overflows and is
> deserialized as negative value (or vice versa, if too large a negative number
> is used).
> Failing test case:
>
> {code:java}
> @Test
> public void shouldNotAcceptOutOfBoundsValue() {
> String json = "{ \"value\": 2147483648 }";
> Jsonb jsonb = JsonbProvider.provider().create().build();
> IntContainer intContainer = jsonb.fromJson(json, IntContainer.class);
> LOG.debug("deserialized value: {}", intContainer.getValue());
> Assert.fail("should throw instead of wrapping the value in negative area");
> }{code}
>
> Log output is:
>
> {noformat}
> SerializationTest deserialized value: -2147483648{noformat}
>
> The expected behavior would probably be an Exception if the number exceeds
> the bounds of the type of the field that the value should be deserialized
> into (byte, short, int, or long).
>
> As additional info, because we researched this when confronted with this
> problem initially (with type int): Applying ijson-strict (rfc7493) doesn't
> help in this situation since there are values that are allowed by the ijson
> rfc and still over-/underflow a 32-bit integer (and it would further require
> us to transmit long values as string).
> Boundaries:
> * 2147483647 max value of signed 32bit integer
> * 9007199254740991 > ijson maxvalue: "senders cannot expect receivers to
> parse numbers larger than..."
> * 9223372036854775807 64b integer
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
