Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-95458

Add support for hexadecimal floating-point format in QLocale, QString and QByteArray

    XMLWordPrintable

    Details

    • Type: Suggestion
    • Status: Reported
    • Priority: P3: Somewhat important
    • Resolution: Unresolved
    • Affects Version/s: 6.2
    • Fix Version/s: None
    • Labels:
      None
    • Platform/s:
      All

      Description

      Since C99, the standard C printf() family of functions have supported a "%a" format for floating point, displayed in hexadecimal,

      a, A (C99; not in SUSv2, but added in SUSv3) For a conversion, the
      double argument is converted to hexadecimal notation (using the
      letters abcdef) in the style [-]0xh.hhhhp±d; for A conversion
      the prefix 0X, the letters ABCDEF, and the exponent separator P
      is used. There is one hexadecimal digit before the decimal
      point, and the number of digits after it is equal to the precision.
      The default precision suffices for an exact representation
      of the value if an exact representation in base 2 exists
      and otherwise is sufficiently large to distinguish values of
      type double. The digit before the decimal point is unspecified
      for nonnormalized numbers, and nonzero but otherwise unspecified
      for normalized numbers. The exponent always contains at least
      one digit; if the value is zero, the exponent is 0.


      alongside the more traditional "%[eEfgG]" format specifiers.
      Our existing number formatting in QLocale, QString and QByteArray supports the traditional format specifiers, so adding support for "%[aA]" would be natural.
      That support uses non-localized representations for bases other than ten; and the printf() family's localized format modifier only applies to decimal output formats, so a locale-independent form is surely acceptable also for this hexadecimal format.

      In QString::vasprintf(), the "%a" format is currently handled by treating it as "%f" (which is doubly wrong: not only is it the wrong base, it's not a mantissa/exponent format). This should clearly be corrected at the same time.

      The spec doesn't make clear whether the exponent is also in hexadecimal, and what base it represents a power of.
      I find (with gcc on Debian) that printf("%a\n", 13.14e14) outputs 0x1.2ac4ddcf08p+50, which is using decimal to specify a power of two.
      Verifying the same is true on other C standard libraries would be prudent.

      Note that modern standard Unix specifications include also an 'F' format, for which infinity and NaN are given upper-cased instead of lower-case.
      This would also be worth adding (and almost no effort – we may, in fact, already support it, by accident, in which case merely updating the docs would suffice).
      It is already (at least superficially) supported by QString::vasprintf().

        Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

            Assignee:
            cnn Qt Core & Network
            Reporter:
            Eddy Edward Welbourne
            PM Owner:
            Vladimir Minenko Vladimir Minenko
            RnD Owner:
            Alex Blasche Alex Blasche
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:

                Gerrit Reviews

                There are no open Gerrit changes