---
- branch: MAIN
  date: Thu May  9 12:24:24 UTC 2024
  files:
  - new: '1.13'
    old: '1.12'
    path: src/lib/libc/gdtoa/hdtoa.c
    pathrev: src/lib/libc/gdtoa/hdtoa.c@1.13
    type: modified
  - new: '1.15'
    old: '1.14'
    path: src/tests/lib/libc/stdio/t_printf.c
    pathrev: src/tests/lib/libc/stdio/t_printf.c@1.15
    type: modified
  id: 20240509T122424Z.0294299adb42bc752ece25ef3c8d1fa439883f23
  log: |
    Revert various broken changes to printf %La (hldtoa).

    This reverts:

    hdtoa.c 1.12 (PR/56247: Greg A. Woods: printf("%La", LDBL_MIN) dumps core)
    hdtoa.c 1.11 (fix tyop)
    hdtoa.c 1.10 (Via enh at google dot com in tech-userlevel. Fix handling of
        EXT_FRAC{H,L}BITS (although we don't need to since we don't have them).)

    The underlying motivation for this change was that when ld128 is
    decomposed into 4x32 words, this hldtoa logic is broken.

    But we don't decompose ld128 into 4x32 words; we decompose it into
    6x64 words.

    And the change, which was supposed to be a noop in our case of 2x64
    words (or similar for x87 80-bit floating-point), broke it to the
    point of causing buffer overruns (PR 56247) which when worked around
    led to just incorrect output output (PR 56937).

    If we want to make the #ifdefs for 4x32 words work, that's fine, but
    we absolutely must have automatic test cases to detect this kind of
    regression because %La formatting is extremely important for
    diagnosing details of floating-point data since it doesn't involve
    rounding in binary formats.  For now I've added some trivial tests;
    there is a more extensive test suite inside gdtoa that we need to
    wire up before anyone tries any other shenanigans in this code.

    PR lib/56937: printf(3) long double %a formatting is broken
  module: src
  subject: 'CVS commit: src'
  unixtime: '1715257464'
  user: riastradh