[Bug stdio/30257] New: *printf of %lc with null argument should not produce a NUL byte

[Bug stdio/30257] New: *printf of %lc with null argument should not produce a NUL byte

[bruno at clisp dot org]

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

            Bug ID: 30257
           Summary: *printf of %lc with null argument should not produce a
                    NUL byte
           Product: glibc
           Version: 2.35
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: stdio
          Assignee: unassigned at sourceware dot org
          Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 14769
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14769&action=edit
test case

According to ISO C and POSIX, use of a narrow *printf function with a %lc
directive and a (wint_t)0 argument should not produce any output.

In glibc, it produces a NUL byte in the output.

Citing ISO C 23 § 7.23.6.1, description of directive 'c':
  "If an l length modifier is present, the wint_t argument is converted
   as if by an ls conversion specification with no precision and an
   argument that points to storage suitably sized for at least two
   wchar_t elements, the first element containing the wint_t argument
   to the lc conversion specification and the second a null wide character."
This is essentially unchanged since ISO C 99.

Citing POSIX
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/snprintf.html
:
  "If an l (ell) qualifier is present, the wint_t argument shall be
   converted as if by an ls conversion specification with no precision
   and an argument that points to a two-element array of type wchar_t,
   the first element of which contains the wint_t argument to the ls [sic!]
   conversion specification and the second element contains a null
   wide character."

The standards _could_ have specified that the functions produce the
multibyte sequence generated by a single wcrtomb call, with a state
initialized to zero. This would have made %lc consistent with %c and
with the wide *wprintf case. But this is not how the standards did it
since 1999 or earlier.

A test case is attached. How to reproduce:
$ gcc -Wall foo.c
$ ./a.out

Actual output:
ret = 2, buf[0] = 0x61, buf[1] = 0x7a, buf[2] = 0x0, buf[3] = 0xdd
ret = 3, buf[0] = 0x61, buf[1] = 0x0, buf[2] = 0x7a, buf[3] = 0x0

Expected output (so far, only musl libc gets it right):
ret = 2, buf[0] = 0x61, buf[1] = 0x7a, buf[2] = 0x0, buf[3] = 0xdd
ret = 2, buf[0] = 0x61, buf[1] = 0x7a, buf[2] = 0x0, buf[3] = 0xdd

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

[Bug stdio/30257] *printf of %lc with null argument should not produce a NUL byte

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

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

[Bug stdio/30257] *printf of %lc with null argument should not produce a NUL byte

[eblake at redhat dot com]

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

Eric Blake <eblake at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eblake at redhat dot com

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

[Bug stdio/30257] *printf of %lc with null argument should not produce a NUL byte

[schwab@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
Confusingly, fwprintf uses the obvious interpretation of %c and outputs a null
character.  Someone should submit a defect report to the C commitee.

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

[Bug stdio/30257] *printf of %lc with null argument should not produce a NUL byte

[bruno at clisp dot org]

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

--- Comment #2 from Bruno Haible <bruno at clisp dot org> ---
(In reply to Andreas Schwab from comment #1)
> Someone should submit a defect report to the C commitee.

Eric Blake has now opened a defect with POSIX, with the intent that both ISO C
and POSIX make the four *printf cases consistent:
https://austingroupbugs.net/view.php?id=1647

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

[Bug stdio/30257] *printf of %lc with null argument should not produce a NUL byte

[bruno at clisp dot org]

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

Bruno Haible <bruno at clisp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTABUG
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Bruno Haible <bruno at clisp dot org> ---
This issue was submitted in the ISO C 23 ballot as GB-141,
and in the meeting from 2023-06-20 to 2023-06-23 it was decided upon:
<https://www.open-std.org/JTC1/sc22/wg14/www/docs/n3167.pdf>
page 23, 24. The decision ("option 1") is detailed in
<https://www.open-std.org/JTC1/sc22/wg14/www/docs/n3148.doc>:
  "Option 1 (require a NUL) - change the text to:
   If an l length modifier is present, the wint_t argument is converted
   as if by a call to the wcrtomb function with a pointer to storage of
   at least MB_CUR_MAX bytes, the wint_t argument converted to wchar_t,
   and an initial shift state."

So, ISO C changed, and POSIX will follow suit.

The glibc behaviour is thus now ISO C compliant. Not a bug any more.

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