From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 73A783858286; Mon, 11 Mar 2024 01:05:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 73A783858286 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1710119130; bh=bJLHs4xJNeniPrq87cwRJlmjkkXjCPVi9+DfdWbd+Y8=; h=From:To:Subject:Date:From; b=cD4no6R2K8CfHWhh6D4LXKfG1AURtpPY2yC3tH0PqagNBvQwuSbmSzsp3+iStJ5Lw 4FOYEG5VMNqh5ZOHZnpaMfyUiBbB++Et0G76QnZGCqFhh/V5k1QLXgsjQR+LicNOzF BCb7bSE3HbdCpYVRwOHAXSNApPEPll6OhvkaiX+0= From: "luigighiron at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/31470] New: inttypes.h provides incorrect macro definitions Date: Mon, 11 Mar 2024 01:05:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: luigighiron at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31470 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 stan= dard in section 7.8.1 "Macros for format specifiers": > The functions in the fprintf and fwprintf families shall behave as if the= y 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 th= en > convert the result of the va_arg expansion to the type corresponding to t= he > macro. For example: #include #include int main(){ uint8_t u=3D-1; printf("%"PRIu8"\n",u+1); } This program should output 0, at least in C23. u contains the value 255, th= en 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 uint= 8_t) and that value is then converted back to uint8_t which will result in the v= alue 0. However, libc (I tested it on godbolt) seems to print 256 here because it d= oes 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 requi= res that the conversion back after va_arg was added by GB-108 (N3148). See N3167 for discussion about accepting GB-108. --=20 You are receiving this mail because: You are on the CC list for the bug.=