Bug #2265

mbsrtowcs does not properly handle invalid mbstate_t in ps

Added by c.turner1 about 3 years ago. Updated about 3 years ago.

Status:NewStart date:12/23/2011
Priority:NormalDue date:
Assignee:swildner% Done:


Target version:-


Was attempting to fix the lang/racket port and discovered a coredump in the autoconf tests -

this coredumps (-HEAD from ~1mo ago / i386 / gcc44):

#include <wchar.h>
int main() {
mbstate_t state;
char *src = "X";
mbsrtowcs(0, &src, 0, &state);
return 0;

whereas this (or passing NULL instead of &state), does not:

#include <wchar.h>
#include <strings.h>
int main() {
mbstate_t state;
bzero(&state, sizeof(mbstate_t));
char *src = "X";
mbsrtowcs(0, &src, 0, &state);
return 0;

As I understand it - posix specifies that this should EINVAL as
it is an 'invalid conversion state'


that being said, I'm not particularly versed in these routines, in which
case, the test case is likely bad, or perhaps this is unspecified in posix.

comments welcome in reguards to these various factors.

I seem to recall some murmurings about updating citrus at some point -
perhaps this issue is resolved upstream there / could be tackled then.

for now, I'll be hacking the configure script and proceeding with the pkg


- Chris


#1 Updated by c.turner1 about 3 years ago

  • Description updated (diff)

well - on further digging - not sure if this is a bug or not..


(non canonical, but 'in the know')


The non-array type mbstate_t is defined to encode the conversion state under the rules of the current locale and provide a character accumulator. This implies that encoding rule information is part of the conversion state. No initialization function is provided to initialize mbstate_t. A zero-valued mbstate_t is assumed to describe the initial conversion state. Such a zero-valued mbstate_t object is said to be unbound. Once a multibyte or wide-character conversion function is called with the mbstate_t object as an argument, the object becomes bound and holds the conversion state information which it obtains from the LC_CTYPE category of the current locale. No comparison function is specified for comparing two mbstate_t objects.

The MSE assumes that only wide-character input/output functions can maintain consistency between a stream and its corresponding conversion state. Byte input/output functions do not manipulate or use conversion state information. Wide-character input/output functions are assumed to begin processing a stream at the boundary between two multibyte characters. Seek operations reset the conversion state corresponding to the new file position.

The function mbsinit() is specified because many conversion functions treat the initial shift state as a special case and need a portable means of determining whether an mbstate_t object is at initial conversion state.

so - not sure if this should imply that:

a) the test is invalid (as it doesn't explicitly initialize a non-static mbstate_t)
b) the failure behavior is/is not invalid - as it could use mbsinit to check
c) some combination - thinking 'c' is it.

and thinking further, should probably check the citrus lib bugs for similar discussion,
so I can just say 'this is in our version', etc.

ok anyhow. bookmark, for the record, in case anyone happens to run into it.
comments welcome if anyone has them. back to porting.

#2 Updated by swildner about 3 years ago

  • Assignee set to swildner

I have a mbsrtowcs() test somewhere I think. I will check it out.

Also available in: Atom PDF