tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [PATCH] Support for mbsnrtowcs and wcsnrtomb

Joerg Sonnenberger wrote:
> On Fri, Apr 26, 2013 at 10:15:17AM +0200, Antoine LECA wrote:
>> +            if (siz == (size_t)-2)
>> +                    err = EILSEQ;
>> if mbrtowc returns -2, it means there is not enough characters
>> (remaining in the buffer) to complete a conversion; however this is not
>> an error condition (yet); and clearly there is no "illegal sequence". In
>> such a case, mbs[n]rtowcs should stop at this point, leaving the rest of
>> the string for a further ("restartable") call; this is achieved by
>> returning *s=s0, i.e. updating the passed-in pointer to point to the
>> still-to-convert string; in other words, just
>>                      goto bye;
>> does the job here.

Well, as I explain elsewhere, it does not, because of

> I'm not sure about that reading of the standard. 

You surely can! Seem others have other ideas than I, and they seem to
have already move :-)

> This applies to mbsrtowcs as well.

Uh? I do not see how.
If the internal call to mbrtowc returns -2, it can only occurs because
the passed "mbcurmax" is "too short", in other words because there are
overlong shift sequences (read the deatils in the Standard description
for mbrtowc); in such a case, in both mbsrtowcs, the implementation can
either retry with a larger value for mbcurmax (to accomodate those
overlong sequences), or just fail. The current behaviour does not seem
completely foolish to me (but a comment could help!)

By the way, for mbsnrtowcs, in that very case, that is if the passed
value (size_t)(se - s0) is >= mbcurmax, then aborting with EILSEQ just
as mbrtowc does, is the correct behaviour.


Home | Main Index | Thread Index | Old Index