Can't round-trip out-of-range floating point

[lionello]

Describe the bug
When parsing a document with an unquoted string that "looks like" a number, the parser will use the float tag, even though the value cannot be represented by the JavaScript number and ends up getting stored as +Inf or -Inf.

To Reproduce
Steps to reproduce the behaviour:

> require("yaml").parse("gitsha: 61e9540")
{ gitsha: Infinity }

Expected behaviour
Like some other YAML loaders (go-yaml comes to mind), an untagged, unquoted value should only be interpreted as a float if it can be safely stored as such in the native type.

Versions (please complete the following information):

• Environment: NodeJS 24.12.0
• yaml: 2.8.1

Additional context
The YAML 1.2 spec is pretty clear:

Some languages (such as Perl) provide only a "number" type that allows for both integer and floating-point values. A YAML [processor] may use such a type for floating-point numbers, as long as they round-trip properly.

[eemeli]

This is indeed an issue that ought to get resolved, probably in a number of different ways.

First of all, the spec text you refer to ought to be considered within its more complete context:

Represents an approximation to real numbers, including three special values (positive and negative infinity and “not a number”).

Some languages (such as Perl) provide only a “number” type that allows for both integer and floating-point values. A YAML processor may use such a type for floating-point numbers, as long as they round-trip properly.

Not all floating-point values can be stored exactly in any given native type. Hence a float value may change by “a small amount” when round-tripped. The supported range and accuracy depends on the implementation, though 32 bit IEEE floats should be safe. Since YAML does not specify a particular accuracy, using floating-point mapping keys requires great care and is not recommended.

What you're seeing is covered by the third paragraph, which excplicitly identifies that numerical values not representable using 32 bits * may change when round-tripped. We could argue about the semantics of whether or not the JS Number's Infinity value differs from 6.1e+95400 by “a small amount”, but it's clearly sub-optimal at the very least, and we ought to improve things here.

For an immediate solution, you can already now parse your content with schema: 'failsafe', which will provide string values for all scalars:

> require("yaml").parse("gitsha: 61e9540", { schema: "failsafe" })
{ gitsha: '61e9540' }

That'll of course emit strings for all scalar values, which might not be what you're looking for. Or maybe it is, given that it looks like you're parsing a GIT SHA value that's getting misidentified as a numerical value?

One part of the solution we can address with #658 and #659, which are adding related features recently introduced to JavaScript's JSON handling.

Another part we address with #660, as we already retain the string source of the value in its Node representation. This won't help with round-tripping all the way with parse(), but that's always been problematic.

And then with #661 we ought to warn users when we're overflowing or losing precision, if that's not too hard to determine.

Having split off those specific fixes, I'm going to leave this open for a consideration of whether there's something else that should also be done to address this. I'm rather dubious about changing the default behaviour to have the type of the parse result depend on the value, as that would easily lead to representing 6195e40 as a Number, while 61e9540 would end up as a String. That seems like a setup for a Norway problem, which would be Not Good.

---

* I'm pretty sure this is meant to refer to IEEE 754 binary32 and not decimal32, but the spec language here should be improved