View Issue Details

IDProjectCategoryView StatusLast Update
00016431003.1(2016/18)/Issue7+TC2System Interfacespublic2024-06-11 09:07
Reporterbhaible Assigned To 
PrioritynormalSeverityEditorialTypeError
Status ClosedResolutionAccepted 
NameBruno Haible
OrganizationGNU
User Reference
Sectionfprintf
Page Number913
Line Number30960
Interp Status---
Final Accepted Text
Summary0001643: fprintf %lc: wrong reference to the current conversion specification
DescriptionThe reference to "the wint_t argument to the ls conversion specification" makes no sense, since an ls conversion specification takes a wchar_t* argument.

In ISO C 99 this paragraph reads
"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 the initial element of a two-element array of wchar_t, the first element
containing the wint_t argument to the lc conversion specification and the
second a null wide character."

So, apparently POSIX and ISO C 99 are based on a common ancestor document, and the reference to "ls" has been corrected in ISO C 99, i.e. changed to "lc".
Desired ActionChange "the wint_t argument to the ls conversion specification" to "the wint_t argument to the lc conversion specification".
Tagsapplied_after_i8d3, tc3-2008

Relationships

related to 0001647 Closed printf("%lc", (wint_t)0) can't output NUL byte 

Activities

eblake

2023-03-21 15:44

manager   bugnote:0006214

For my own reference as much as anything else, Bruno found this while reporting a corner-case bug in glibc's printf(): https://sourceware.org/bugzilla/show_bug.cgi?id=30257
and which he found to be also present in most other tested libc except musl.

Namely, narrow printf("%lc", (wint_t)0) is surprisingly required to produce 0 bytes instead of the multibyte sequence for the null character, because that is the behavior of %ls with no precision when handed a wchar_t array with a null character in the first index; and this behavior is both different than the wprintf behavior, and from the %c behavior with a NUL byte.

Issue History

Date Modified Username Field Change
2023-03-21 11:13 bhaible New Issue
2023-03-21 11:13 bhaible Name => Bruno Haible
2023-03-21 11:13 bhaible Organization => GNU
2023-03-21 11:13 bhaible Section => fprintf
2023-03-21 11:13 bhaible Page Number => 913
2023-03-21 11:13 bhaible Line Number => 30960
2023-03-21 15:44 eblake Note Added: 0006214
2023-03-28 16:32 eblake Relationship added parent of 0001647
2023-04-20 16:22 geoffclare Relationship replaced related to 0001647
2023-04-20 16:23 geoffclare Interp Status => ---
2023-04-20 16:23 geoffclare Status New => Resolved
2023-04-20 16:23 geoffclare Resolution Open => Accepted
2023-04-20 16:23 geoffclare Tag Attached: tc3-2008
2023-06-13 10:45 geoffclare Status Resolved => Applied
2023-06-13 10:46 geoffclare Tag Attached: applied_after_i8d3
2024-06-11 09:07 agadmin Status Applied => Closed