On Tuesday 26 May 2009 18:40:23 Bruno Haible wrote: > Mike Frysinger wrote: > > i dont see any checks/replacements for when MB_CUR_MAX does not exist > > This is because MB_CUR_MAX is part of ANSI C + amendment 1 (ca. 1995), and > no platforms are known that lack it (see > gnulib/doc/posix-headers/stdlib.texi). > > Likewise for mbtowc(): It's present on all platforms we care about, see > gnulib/doc/posix-functions/mbtowc.texi. > > > (like in a uClibc build where all multibyte > > related stuff has been disabled). for example, zile falls apart like so: > > ../../zile-2.3.7/lib/mbrtowc.c: In function ‘rpl_mbrtowc’: > > ../../zile-2.3.7/lib/mbrtowc.c:96: warning: implicit declaration of > > function ‘mbtowc’ ../../zile-2.3.7/lib/mbrtowc.c:124: error: ‘MB_CUR_MAX’ > > undeclared (first use in this function) > > There is an easy way out: just don't disable all multibyte related stuff > in uClibc. > > uClibc has this code, that's what you're saying. Therefore there's no point > in gnulib to duplicate this functionality. All other platforms have > ANSI C + amendment 1.
it's disabled explicitly because we dont want multibyte sucking up space on a system that doesnt need it. there are a few packages (like zile) which dont currently have a way of disabling the multibyte workarounds. i figured it'd be a two pronged approach: fix gnulib and fix zile. you're saying this breakage is "by design" with gnulib, so that's that. -mike
signature.asc
Description: This is a digitally signed message part.
