[Bug libc/31470] New: inttypes.h provides incorrect macro definitions

[Bug libc/31470] New: inttypes.h provides incorrect macro definitions

[luigighiron at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31470

            Bug ID: 31470
           Summary: inttypes.h provides incorrect macro definitions
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: luigighiron at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

The inttypes.h header provides macros for printing out the types defined in
inttypes.h and stdint.h. In C23, the following text was added to the C standard
in section 7.8.1 "Macros for format specifiers":

> The functions in the fprintf and fwprintf families shall behave as if they use
> va_arg with a type argument naming the type resulting from applying the
> default argument promotions to the type corresponding to the macro and then
> convert the result of the va_arg expansion to the type corresponding to the
> macro.

For example:

#include<stdio.h>
#include<inttypes.h>
int main(){
    uint8_t u=-1;
    printf("%"PRIu8"\n",u+1);
}

This program should output 0, at least in C23. u contains the value 255, then
one is added which results in the value 256 (after integer promotions). 256 is
provided to printf which will do va_arg with int (the promoted type of uint8_t)
and that value is then converted back to uint8_t which will result in the value
0.

However, libc (I tested it on godbolt) seems to print 256 here because it does
not do the conversion back to uint8_t. This seems to be because libc defines
PRIu8 here as "u". I tested this on MSVC and Cygwin and it printed 0 as
expected, with those compilers it is defined as "hhu". The text which requires
that the conversion back after va_arg was added by GB-108 (N3148). See N3167
for discussion about accepting GB-108.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31470] inttypes.h provides incorrect macro definitions

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31470

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com,
                   |                            |jsm28 at gcc dot gnu.org

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
Interesting.

Joseph, should we change most of the <inttypes.h> macro definitions
accordingly? I don't have access to C23, but the wording in C11 suggest to me
that the example violates the precondition set in 7.8.1p1. It's hard to
interpret though due to default argument promotions, though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31470] inttypes.h provides incorrect macro definitions

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31470

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
I don't think PRIu8 is a valid format for u+1, since u+1 is of type int, not
uint8_t, and u+1 is not in range for uint8_t.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31470] inttypes.h provides incorrect macro definitions

[luigighiron at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31470

--- Comment #3 from Halalaluyafail3 <luigighiron at gmail dot com> ---
(In reply to Andreas Schwab from comment #2)
> I don't think PRIu8 is a valid format for u+1, since u+1 is of type int, not
> uint8_t, and u+1 is not in range for uint8_t.

PRIu8 is supposed to work with the promoted type of uint8_t (always int) then
convert to uint8_t. So it should output 0, similar to how using unsigned char
and "hhu" would work. See the quote from C23 that I provided in the bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31470] inttypes.h provides incorrect macro definitions

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31470

--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> ---
I don't see how that paragraph supports this.  It does not say that you can
pass arbitrary values outside the range of the type.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31470] inttypes.h provides incorrect macro definitions

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31470

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-03-11
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #5 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
CD2 GB-108 is indeed on my list of accepted NB comments requiring
implementation changes - the macro definitions should be changed, with
associated tests added to the glibc testsuite. The general rule that you can
pass a value of the promoted type (or, in certain cases, a signed/unsigned
variant of that type, when the rules for va_arg allow such variations), not
necessarily arising from promotion of a value of the narrower type, was
introduced for N2562 (previously this area was unclear). CD2 GB-108 simply
makes the macros in inttypes.h follow the same rules required to be followed by
direct use of formats such as %hhd.

When %hh / %h formats are used directly, glibc has done the expected narrowing
since 2006 (bug 2509; glibc 2.5; "(process_arg): Fix reading of signed short
and byte values from parameter list."). It's just the macros that now need
fixing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31470] inttypes.h provides incorrect macro definitions

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31470

--- Comment #6 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Although https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf is a C2y
draft, it's technically identical to C23 (various editorial fixes have gone
into C23 since then, but that draft doesn't have any technical C2y changes).

-- 
You are receiving this mail because:
You are on the CC list for the bug.