Lookup(Δ, Γ, f) must be fround and n must be a floating-point literal with the character . in its source.
This is not how it is used though, as Emscripten generates and Firefox validates without the ‘.’ character. My initial thought was that maybe the validation rule was actually being treated as any fround(NumericLiteral), which would essentially be the integer range [-2^31, 2^32), or any numeric literal with a ‘.’ present.
However, this does not seem to be the case either, as Firefox validates any numeric literal, without respect to how NumericLiteral is defined in the spec or used elsewhere. To me this seems inconsistent, so what should the behavior be? My opinion on the matter is that it should be handled the same as NumericLiteral elsewhere.
You are exactly right, FF accepts any Math.fround((-)NumericLiteral). I found this in an asm.js spec audit a few weeks ago and put this on a list of things to fix for the next spec update, but unfortunately we haven’t made that update yet. In the meantime, here’s the list: https://etherpad.mozilla.org/ibPVJ81u35
The basic idea is that fround can show up in places that normal calls can’t (in coercion contexts like parameters where we don’t want to allow arbitrary code execution) and fround gives the validation rules a special way to say “just allow the magic fround function here”.
Another question (posting here since related to NumericLiteral) - in section 5.2 (Return Type Annotations) it’s said:
has return type double if n is composed of a floating-point
literal, i.e., a numeric literal with the character . in
its source; alternatively, if n is composed of an integer
literal and has its value in the range [-2^31,
2^31), the return statement has return
but in 5.4 (Variable Type Annotations):
the variable type is double
if n’s source contains the character .;
otherwise n may be an integer literal in the range
[-2^31, 2^32), in which case the variable type
Which is different in two ways:
higher bound is 2^31 vs 2^32
type is signed vs int
I guess those are supposed to be the same, so there is some kind of mistake here?