Comments (4)
This is what various parsers do right now, grouped by how they handle it:
% ./run test <<<'a=1e1000000000'
c++-toml++ ERROR: Error while parsing floating-point: '1e1000000000' could not be interpreted as a value (error occurred at line 1, column 15 of 'stdin')
c++-toml11 ERROR: what(): [error] toml::parse_floating: --> unknown file | 1 | a=1e1000000000 | ^--- out of range
c-toml-c ERROR: unknown type{"a":
c-tomlc99 ERROR: unknown type{"a":
go-go-toml ERROR: Error decoding TOML: toml: unable to parse float: strconv.ParseFloat: parsing "1e1000000000": value out of range
go-toml ERROR: Error decoding TOML: toml: line 1 (last key "a"): 1e1000000000 is out of range for float64
lisp-clop ERROR: arithmetic error FLOATING-POINT-OVERFLOW signalled
racket-toml-racket ERROR: loading code: version mismatch expected: "8.12" found: "8.11.1" in: #<input-port:string> possible solution: running `racket -y`, `rac
rust-basic-toml ERROR: Error: Error { message: "invalid number at line 1 column 3" }
rust-toml ERROR: Error: Error { message: "TOML parse error at line 1, column 3\n |\n1 | a=1e1000000000\n | ^\ninvalid floating-point number\n" }
rust-toml_edit ERROR: Error: Error { message: "TOML parse error at line 1, column 3\n |\n1 | a=1e1000000000\n | ^\ninvalid floating-point number\n" }
cs-tomlyn {"a":{"type":"float","value":"+inf"}}
dart-toml.dart {"a":{"type":"float","value":"infinity"}}
fortran-toml-f {"a":{"type":"float","value":"+inf"}}
haskell-toml-parser {"a":{"type":"float","value":"inf"}}
haskell-toml-reader {"a":{"type":"float","value":"inf"}}
js-iarna-toml {"a":{"type":"float","value":"Infinity"}}
js-j-toml {"a":{"type":"float","value":"Infinity"}}
js-smol-toml {"a":{"type":"float","value":"inf"}}
js-toml-eslint-parser {"a":{"type":"float","value":"+inf"}}
python-toml {"a":{"type":"float","value":"inf"}}
python-tomli {"a":{"type":"float","value":"inf"}}
python-tomlkit {"a":{"type":"float","value":"inf"}}
python-tomllib {"a":{"type":"float","value":"inf"}}
ruby-perfect_toml {"a":{"type":"float","value":"+inf"}}
ruby-toml-rb {"a":{"type":"float","value":"+inf"}}
ruby-tomlrb {"a":{"type":"float","value":"+inf"}}
rust-taplo {"a":{"type":"float","value":"inf"}}
ocaml-otoml {"a":{"type":"float","value":"1e+1000000000"}}
guile-toml {"a":{"type":"float","value":"1e1000000000"}}
11 error out, 17 use inf, and 2 seem to handle this (although I didn't verify if they also handle it correct). I think both erroring and using Inf is reasonable.
As I understand that issue, Numeric.readFloat "1e1000000000"
taking 35 seconds seems very specific to how Haskell works(?)
This isn't really specified in the TOML spec at the moment; I'm not sure we need to either: practically speaking, it also seems to be a non-issue, and at least allowing support for floats >64bit isn't a bad thing?
Can add a note to: https://github.com/toml-lang/toml-test?tab=readme-ov-file#untested-and-implementation-defined-behaviour ?
from toml-test.
Thanks for putting that summary together so quickly.
You're right that the bad behavior on overflow in toml-reader
was specifically to a GHC base library behavior, and isn't likely to be duplicated across languages. I only included in the ticket because it was somewhat connected.
I think allowing floats >64-bits is probably a bad thing. Uncertainty about what values are in range leads to incompatibility between TOML implementations.
Floats should be implemented as IEEE 754 binary64 values.
I think it's a good thing that the spec gives us this kind of clarity about floats in TOML and I'm disappointed in JSON, for example, for punting on this.
Arbitrary 64-bit signed integers (from −2^63 to 2^63−1) should be accepted and handled losslessly. If an integer cannot be represented losslessly, an error must be thrown.
TOML says that for integers a lossy parse should through an error and at least defines a minimum acceptable range. I think it's great that it defines both a minimum and an error behavior. The fact that lossy conversions are defined to error suggests to me that it's the right answer for TOML floats but that's just an interpretation.
Being explicit that this behavior isn't tested sounds like a fine resolution to me.
(I'm quite aware that the opinions I've expressed are opinions and that this repository isn't the place to define new behaviors of TOML. I've just been leaning on it to have good tests for as many defined behaviors as possible :-D )
from toml-test.
"Should" is a bit of an ambiguous term, but the way I'm reading that doesn't exclude being able to handle higher precision floats, or even supporting only 32bit floats.
As you mentioned, this is more of a specification issue rather than a toml-test issue. Integers specified much more precisely:
32-bit signed integers (from −2^31 to 2^31−1) must be accepted and handled
losslessly. 64-bit signed integers (from −2^63 to 2^63−1) should be accepted and
handled losslessly. A larger range may also be accepted.An error must be thrown if a given integer cannot be represented losslessly.
But of course, floats are never "lossless" in the same way ints are.
At the very least the specification should be changed to define a minimally supported range similar to ints, so you know what you can rely on with 100% certainty.
from toml-test.
Since my request is impossible to satisfy (the behavior isn't defined enough to write a test) I'll go ahead and retract it. Thanks for the discussion.
from toml-test.
Related Issues (20)
- Installation from conda-forge
- Bug in Test Case: valid/string/multiline-quotes HOT 2
- Add tests for unicode in bare keys
- Add test for tab character HOT 2
- Add tests for invalid encodings in all string types HOT 2
- Generate tests from the spec? HOT 8
- Add tests for "Permit more control characters in comments"
- Contradicting tests `invalid/no-seconds.toml` and `valid/no-seconds.toml` HOT 6
- Millisecond truncation is incorrect HOT 1
- Millisecond decoder tests pass with second precision output HOT 1
- Transfer to the toml-lang organisation? HOT 7
- Split `invalid/float/trailing-us-exp.toml` into two tests HOT 5
- valid/table/array-one fails when using inline array and table HOT 2
- Consider adding some performance tests HOT 1
- Invalid Unicode Escapes HOT 4
- [Valid Tests] Add Extra Spaces in Inline Tables HOT 1
- Clarify if - is permitted as a starting character in bare keys (toml 1.0.0) HOT 1
- Add tests for newlines within an array nested in an inline table
- Inconsistent test result of '+inf' HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from toml-test.