Request for clarification: floating point literal mangling

[Zack Weinberg]

The current text referring to the mangling of floating-point literals
in template parameters has a number of ambiguities.  Here's what it
says:

     Floating-point literals are encoded using a fixed-length lowercase
     hexadecimal string corresponding to the internal representation
     (IEEE on Itanium), high-order bytes first, without leading
     zeroes. For example: "Lf bf800000 E" is -1.0f on Itanium.

I see four problems:

1) It is not clear what "internal representation" means.  The example
   suggests that the intent is to use the bit pattern that the
   processor would store in memory, considered as an integer.
   However, it might also refer to the compiler's internal
   representation of floating point numbers, which may or may not be
   the same thing.

2) "Fixed length" and "without leading zeroes" contradict each other.

3) Assuming that "without leading zeroes means, e.g. that the mangling
   of the denormalized single precision float 1.40129846e-45f is
   "Lf 1 E", it is not clear whether 0.0f should be mangled as
   "Lf 0 E" or "Lf E".

4) The example indicates that the "n" prefix is not used for negative
   floating point literals, but the text doesn't make that clear.

I would like to propose the following reworded text.

     Floating-point literals are encoded using the bit pattern of the
     target processor's internal representation of that number, as a
     lowercase hexadecimal string, high-order bytes first (even if the
     target processor would store low-order bytes first).  Leading
     zeroes are not included; if the pattern is all bits zero, the
     encoding is the empty string.  The "n" prefix is not used for
     floating-point literals; the sign bit is encoded with the rest of
     the number.

     Here are some examples, assuming the IEEE standard representation
     for floating point numbers.  (Spaces are for readability, not
     part of the encoding.)

         1.0f                    Lf 3f80 0000 E
        -1.0f                    Lf bf80 0000 E
         1.17549435e-38f         Lf   80 0000 E
         1.40129846e-45f         Lf         1 E
         0.0f                    Lf           E


Alternatively, we could abandon the leading zero stripping, which does
make life a bit easier on an implementation; it's not much of an
optimization considering that almost all floating point numbers have a
nonzero exponent field.  In that case, my proposed wording would be

     Floating-point literals are encoded using the bit pattern of the
     target processor's internal representation of that number, as a
     fixed-length lowercase hexadecimal string, high-order bytes first
     (even if the target processor would store low-order bytes first).
     The "n" prefix is not used for floating-point literals; the sign
     bit is encoded with the rest of the number.

     Here are some examples, assuming the IEEE standard representation
     for floating point numbers.  (Spaces are for readability, not
     part of the encoding.)

         1.0f                    Lf 3f80 0000 E
        -1.0f                    Lf bf80 0000 E
         1.17549435e-38f         Lf 0080 0000 E
         1.40129846e-45f         Lf 0000 0001 E
         0.0f                    Lf 0000 0000 E

Does anyone have a preference for one or the other?  Objections to
other clarifications?

zw

p.s. Please cc: me on replies, I'm not subscribed to this list.