Skip to content

Define appropriate implementation behaviors for extreme values #538

@jongiddy

Description

@jongiddy

One thing that I would like to see defined before 1.0 is the behavior when implementation limits are reached. This would consist of an explicit statement that TOML itself does not have a limit but that parsers may.

For example:

Strings can have any length. However, parsers may produce an error for strings that are too long for them to safely handle.

Integers can have any length. Parsers must produce an error if the value cannot be represented in an internal type. Parsers must not produce an integer that does not equal the full value represented in the TOML and must not produce a string representation of the value.

And perhaps most debatable, what happens to very large or very small floats (e.g. 1e500 and 1e-500). Programming languages often convert these to inf or 0. For configuration, I'd consider it more appropriate to produce an error. For example, a very small float may represent an epsilon value or error allowance, and should produce an error rather than be rounded down to zero.

Numeric floats do not convert to ±inf. The parser should produce an error if the float is too large to be represented as a non-infinite float.
Floats that contain a non-zero mantissa do not convert to zero. The parser should produce an error if the float is too small to be represented as a non-zero float.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions