mbrtowc(3) state after an invalid sequence "undefined" or "unspecified"?

[Mark Brown]

On 5/21/26 10:08 AM, Kang-Che Sung wrote:
> Hi, Alejandro (or anyone else interested),
>
> 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.

I happen to be on the Austin Common Standards Revision Group (the POSIX 
standards committee); I can open an issue on the subject here 
https://www.austingroupbugs.net/ if you would like. For your current 
needs, note that the POSIX 2024 standard entry for these functions 
contains the following statement:

"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."

Thus, you should be safe to assume ISO C semantics here until a ruling 
is reaching on the POSIX document.

regards.
Mark

-- 
Mark Brown
mstevenbrown@gmail.com