>> 	- we now ship with correct locale table, and lib/libc/locale/runeglue.c
>> 	  converts it into _ctype_.  now _ctype_ can have correct locale bit
>> 	  declarations and isprint() can behave strange.
>I think we didn't ship _ctype_[] table with ((_ctype_+1)['\t'] & _B) != 0
>in any release version. Is this right?
>If so, because we don't have to keep bug-compatibility with -current, ...

	it seems that there are people using locale declaration file
	(/usr/share/locale/*/LC_CTYPE) compiled by chrtbl(8).
	there's no guarantee about the above statement.  

	however, if ((_ctype_+1)['\t'] & _B) != 0, isprint will get broken
	(about isprint('\t')) so a locale table with
	((_ctype_+1)['\t'] & _B) != 0 could be considered as bogus.

>> 	1c. don't change ctype.h declarations.
>> 	    when we load locale declaration file, we make some trick about _B.
>> 	    PROS: smallest amont of changes.
>> 	    CONS: new binaries will have incorrect isprint() and isblank(),
>> 		forever.
>How about a variant of this?

	i've workarounded  the problem it by keeing _ctype_ as is, and tweaking
	lib/libc/locale/rune{,glue}.c.  does it look okay?  i changed nothing
	in ctype.h nor lib/libc/gen/isctype.c.

	i really would like to see newer binaries use
	__CurrentRuneLocale.__runetype[] instead of _ctype_.  i'm not very
	happy about letting future programs to look at _ctype_.
	(then, again i'm stuck with problem with dlopen and locale code...)

itojun