NumericLiteral and fround


#1

In the asm.js spec, see that for variable type annotations, it says:

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.


#2

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


#3

Could you please explain why was special type fround added specifically for this function? Trying to figure out how is it different from (double)->float ^ ....


#4

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”.


#5

So it’s just kind of strict alias for Math.fround itself and not an actual type?


#6

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 type signed

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 is int.

Which is different in two ways:

  1. higher bound is 2^31 vs 2^32
  2. type is signed vs int

I guess those are supposed to be the same, so there is some kind of mistake here?

https://etherpad.mozilla.org/ibPVJ81u35 doesn’t seem to mention any of those