search

amnaredo / test

0 stars 0 forks source link

Unexpected result when parsing of too big integer or floating point numbers without dot as numeric primitives #245

Open amnaredo opened 3 years ago

amnaredo commented 3 years ago 
scala> upickle.default.read[Byte]("999")
res0: Int = -25

scala> upickle.default.read[Byte]("0e0")
res1: Int = 18

scala> upickle.default.read[Short]("99999")
res2: Short = -31073

scala> upickle.default.read[Short]("0e0")
res3: Short = 530

scala> upickle.default.read[Char]("99999")
res4: Char = 蚟

scala> upickle.default.read[Char]("0e0")
res5: Char = Ȓ

scala> upickle.default.read[Int]("9999999999")
res6: Int = 1410065407

scala> upickle.default.read[Int]("0e0")
res7: Int = 530

scala> upickle.default.read[Long]("0e0")
res8: Long = 530

ID: 259 Original Author: plokhotnyuk

amnaredo commented 3 years ago

read assumes you give it a correct type param.

You can't rely on read throwing an exception if you give it an incorrect type param because in general it is impossible to make such a guarantee, as values of different types can be serialized into the same JSON. Original Author: raquo

amnaredo commented 3 years ago

We can nevertheless be stricter than we are now throwing exceptions for out-of-bounds numbers, and the bad parsing of 0e0 notation is just a bug Original Author: lihaoyi

amnaredo commented 3 years ago

@raquo The type param is correct. Original Author: yarulan

amnaredo commented 3 years ago

Handling of exponents is fixed by https://github.com/lihaoyi/upickle/commit/1d4ae8e066292a14e4f958953228ef1ba31bd097, going to call integer overflow and wrap-around a wontfix for now Original Author: lihaoyi