Skip to content

Float to integer casts can have undefined results #28382

Closed
@Aatch

Description

@Aatch

By accident I came across an ICE from this code: (-1.0 as usize,). The ICE is triggered by an assertion while building the constant tuple. The field has a value of undef.

Looking into it, the two floating point to integer cast instructions, fptoui and fptosi have a very large surface for producing undefined values. Any time the result cannot fit into the destination type, the result is undefined. This means casting from a negative float to an unsigned integer is undefined and casting from a float with a value outside the range for the target integer type (signed or otherwise) is undefined.

Some possible solutions:

  1. Treat it as an error always. This means generating an assertion before the cast, similar to how we generate assertions to check for divide-by-zero.
  2. Clamp the value. Casting from outside the valid range will clamp to one end of the range. so -1.0 as u32 would produce 0.
  3. A combination of both. Treat the case similarly to how we treat integer overflow and emit an assertion in debug builds, but omit them in release builds, falling back to the clamping behaviour.

I'm personally leaning towards 3. Most of the time an invalid cast of this nature will be unintentional, so protecting against it seems reasonable. The problem is also similar enough to overflowing that handling it similarly seems reasonable.

/cc @rust-lang/compiler @rust-lang/lang

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions