Re: [PATCH] Fix printf(1) for integer larger than INTMAX_MAX

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 25 Oct 2020 19:01:18 +0900
    From:        Rin Okuyama <rokuyama.rk%gmail.com@localhost>
    Message-ID:  <09f349b6-f483-e582-d5b4-71f6b747db56%gmail.com@localhost>

  | I forgot to mention in the previous message: %[oux] also fail for numbers
  | larger than 1<<63:

Yes, so they do - that's a (relatively) recent regression (which
probably means I caused it) and should certainly be fixed.

  | This is because we convert unsigned integers by strtoimax(3). So, I've
  | updated the patch:
  |
  | http://www.netbsd.org/~rin/printf_20201025.patch

Apart from the change to getwidth() (from ulong to uintmax_t) which isn't
really needed, this is for handling field width values, and we arbitrarily
silently truncate those (to a megabyte) already - an unsigned long can
easily cope with any value we're actually going to use, the rest of that
looks fine to me.

There are probably (ugly) ways to deal with the commented out tests (because
we have no simple way to know what range of values printf supports, so can't
tell at what point errors, and value truncation, will start happening).  For
the purposes of ATF tests (rather than generic sh programming) there are
probably a sequence of operations that can be performed, where the results
are not used for pass/fail of the test, but for deciding what later tests to
run, perhaps using something like the method used in the sh arithmetic test
which has the same needs (but which has the advantage of being able to use
arithmetic to assist finding the range of values it supports).   That is,
the details would vary, but the general method should be able to be made to
work.

kre