Re: Wrong formatting of doubles?

[Jeffrey Walton <noloader@gmail.com>]

On Tue, Jul 1, 2025 at 12:38 PM Rich Felker <dalias@libc.org> wrote:
>
> > > On Tue, Jul 01, 2025 at 07:55:20AM +0200, Michal Terepeta wrote:
> > > > Hi,
> > > >
> > > > We're working on a RISC-V system and using musl as our libc. A recent change
> > > > in musl seems to have caused wrong formatting (printf) of double values:
> > > > https://git.musl-libc.org/cgit/musl/commit/src/stdio/vfprintf.c?id=572a2e2eb91f00f2f25d301cfb50f435e7ae16b3
> > > > [...]
> [...]
> I'd also like to think about ways we could avoid introducing bugs like
> this in the future. In this case, just a testcase for printing DBL_MAX
> in multiple formats would likely have caught it. Simple trapping-only
> UBsan might have caught it, but I'm not sure if that would follow all
> the positional arithmetic in fmt_fp to detect going outside the object
> bounds. This may be worth investigating.

Yes, test cases under a tool like a memory checker or UB checker are
the way to go. In this case, the sanitizers or Valgrind likely would
have alerted to the problematic code.

Another trick I like to use in debug builds is the use of asserts to
verify all program state. In this case, you might be able to check if
a pointer is within a particular range. In release builds, the checks
can be omitted since they were already verified using a test case in
debug builds, so the code will not take a performance hit.

When I perform root cause analysis on why a bug hit production, it
just about always (always?) includes a missing test case.

Jeff