View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001982 | 1003.1(2024)/Issue8 | System Interfaces | public | 2026-05-28 12:10 | 2026-05-28 16:15 |
| Reporter | alx | Assigned To | |||
| Priority | low | Severity | Editorial | Type | Error |
| Status | Interpretation Required | Resolution | Accepted | ||
| Name | Alejandro Colomar | ||||
| Organization | Linux man-pages | ||||
| User Reference | |||||
| Section | mbrtowc, mbrstowcs | ||||
| Page Number | 1394, 1397 | ||||
| Line Number | 46796, 46920 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | see desired action | ||||
| Summary | 0001982: probably-unintended wording difference with ISO C in mbrtowc(3) and mbrtowcs(3) | ||||
| Description | I'm forwarding a report I received by email from someone else. On 2026-05-21T23:08:20+0800, Kang-Che Sung wrote: > There's a discrepancy in the wording of the mbrtowc(3) function (and > similarly, mbsrtowcs(3) function) between in POSIX and ISO C. It could be > reported as an issue to POSIX (the Austin Group), and I am not sure if you > can do that. > > In ISO C (I checked in both C99 and C23, in particular the N3220 draft), > there's a statement that if mbrtowc() returns a (size_t)(-1) as an encoding > error occurs, "the conversion state is unspecified". > > POSIX (see < > https://pubs.opengroup.org/onlinepubs/9799919799/functions/mbrtowc.html>), > for the same part it says "the conversion state is undefined". > > This wording difference matters when the "unspecified behavior" and > "undefined behavior" are technically different. An example is how the > mbstate_t object can be reused after an invalid sequence is encountered. > When the state is said to be "undefined" it's implied to be not usable > again (unless it is reset, e.g., by an `mbrtowc(NULL, "", 1, ps)` call). > When it's "unspecified" then implementations can allow the state to be > reused for certain encodings (possible for UTF-8, for example). > > This is something I discovered accidentally when researching the multibyte > functions in the C standard library and how they work with an encoding like > UTF-8. Reported-by: Kang-Che Sung <explorer09@gmail.com> | ||||
| Desired Action | wording fix: s/undefined/unspecified/ in the right place in RETURN VALUE. | ||||
| Tags | tc1-2024 | ||||
|
|
Interpretation response ------------------------ The standard clearly states that the functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of POSIX.1-2024 defers to the ISO C standard, and conforming implementations must conform to this. Rationale: ------------- N/A Notes to the Editor (not part of this interpretation): ------------------------------------------------------- See desired action |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-05-28 12:10 | alx | New Issue | |
| 2026-05-28 14:48 | msbrown | Page Number | I don't know => 1394 |
| 2026-05-28 14:48 | msbrown | Line Number | I don't know => 46796 |
| 2026-05-28 14:48 | msbrown | Interp Status | => --- |
| 2026-05-28 14:50 | msbrown | Page Number | 1394 => 1394, 1397 |
| 2026-05-28 14:50 | msbrown | Line Number | 46796 => 46796, 46920 |
| 2026-05-28 16:12 | nick | Status | New => Resolved |
| 2026-05-28 16:12 | nick | Resolution | Open => Accepted |
| 2026-05-28 16:12 | nick | Final Accepted Text | => see desired action |
| 2026-05-28 16:15 | nick | Status | Resolved => Interpretation Required |
| 2026-05-28 16:15 | nick | Note Added: 0007434 | |
| 2026-05-28 16:15 | nick | Tag Attached: tc1-2024 |
