mbsrtowcs and EILSEQ

[Antoine Leca]

Hi,

I am reading http://austingroupbugs.net/view.php?id=616 which redefines
the definition of POSIX:2008 additional mbsnrtowcs, but meanwhile it
also modifies (a small bit) their version of mbsrtowcs:

[...] change:

past the last character converted (if any)

to:

past the last byte processed (if any)

That part is outside the "CX-shaded" text, so applies to mbsrtowcs when
implemented on POSIX-compliant systems when one discards the "Any
conflict between the requirements described here and the ISO C standard
is unintentional" boilerplate.

For reference, C11 7.29.6.4.1p3 reads as
[#3] If /dst/ is not a null pointer, the pointer object pointed
to by /src/ is assigned either a null pointer (if conversion
stopped due to reaching a terminating null character) or the
address just past the last multibyte character converted (if
any). If conversion stopped due to reaching a terminating null
character and if /dst/ is not a null pointer, the resulting
state described is the initial conversion state.

(The affected text is in the middle of the paragraph.)


The way I am understanding it, the difference can only be noticed for
the value to be returned in *src when an EILSEQ occurs: in such a case,
under the C99/C11 Standard you can reset the mbstate_t --since it's now
undefined-- and then restart some process from the updated *src, which
holds the pointer "past the last converted multibyte", ie a pointer to
the start of still unconverted part.
Under the Austin-group reading *src is to be updated to "last byte
processed" which can be anything since the process detected an error;
the potential for restarting is now close to 0. Worse, you cannot know
exactly where you can insert a \0 to transform the original input string
into a valid one (for example, to print some error report context.)

I understand implementations are following the same ideas as Austin
Group commentators and probably some do not fully observe the
requirements of the C99/C11 Standard (thus botching the value returned
in *src.) However I am not presently in position to test many of them;
according to the Austin Group discussion, GLibC, FreeBSD, and MacOSX are
all following the amended behaviour for the mbsnrtowcs function, but it
does not mean anything for their behaviour upon mbsrtowcs.

I also understand that the overwhelming majority of programs using that
functions just abort when EILSEQ is detected. But this is comp.std.c.


Antoine

[Geoff Clare]

Antoine Leca wrote:

> I am reading http://austingroupbugs.net/view.php?id=616 which redefines
> the definition of POSIX:2008 additional mbsnrtowcs, but meanwhile it
> also modifies (a small bit) their version of mbsrtowcs:
>
> [...] change:
>
> past the last character converted (if any)
>
> to:
>
> past the last byte processed (if any)
>
> That part is outside the "CX-shaded" text, so applies to mbsrtowcs when
> implemented on POSIX-compliant systems when one discards the "Any
> conflict between the requirements described here and the ISO C standard
> is unintentional" boilerplate.

In a teleconference yesterday, the Austin Group decided to alter the
way this change is being done, so that there can be no question of
a possible conflict.

See http://austingroupbugs.net/view.php?id=616#bugnotes

--
Geoff Clare <net...@gclare.org.uk>

[Antoine Leca]

Geoff Clare wrote:
> In a teleconference yesterday, the Austin Group decided to alter the
> way this change is being done, so that there can be no question of
> a possible conflict.

Great, thanks for the head-up and also thanks to AG to be so attentive!

Now I should go back to try to sanely implement mbsnrtowcs...


Antoine