[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8=kmYz+WGWMmqWZ8psv_tQ9dUk1ai1qWXkswMVPKiXytA@mail.gmail.com>
Date: Tue, 1 Jul 2025 13:02:44 -0400
From: Jeffrey Walton <noloader@...il.com>
To: musl@...ts.openwall.com
Cc: Michal Terepeta <michalt@...gle.com>, t5y-external <t5y-external@...gle.com>
Subject: Re: Wrong formatting of doubles?
On Tue, Jul 1, 2025 at 12:38 PM Rich Felker <dalias@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
