I can' t understand why this change is needed.
POSIX2008 spec say, *_l func with invalid locale handle may EINVAL.
NULL or (locale_t)0 is invalid locale handle.
why are you think fallback to C locale?
http://pubs.opengroup.org/onlinepubs/9699919799/functions/isalpha.html
Hi,
It seems that lint(1) is not cross build safe, it doesn't handle MD char
default type of sign/unsignd. See src/usr.bin/xlint/lint1/tree.c::cvtcon().
They use host MD CHAR_MAX directry ;)
So, if cross building ppc/arm on other arch cause false alarm , out of
range warnng.
Regards.
--
Hi,
It seems that lint(1) is not cross build safe, it doesn't handle MD char
default type of sign/unsignd. See src/usr.bin/xlint/lint1/tree.c::cvtcon().
They use host MD CHAR_MAX directry ;)
So, if cross building ppc/arm on other arch cause false alarm , out of
range warnng.
very truly yours.
character, we have to provide
phonogram bit too.
i'll post patch to tech-userlevel@, this weekend or next week.
very truly yours.
--
Takehiko NOZAKI tnoz...@netbsd.org
for libedit.
# but it still need lots of time.
very truly yours.
--
Takehiko NOZAKItakehiko.noz...@gmail.com
2010/1/14 Takehiko NOZAKI takehiko.noz...@gmail.com:
hi, all.
i found following problems this patch:
1. don't write UTF-8 locale dependent ``cheat'' code in locale
independent libedit
convert multibyte - wide-character is
# EL_BUILTIN_GETCFN(=read_char) itself.
very truly yours.
--
Takehiko NOZAKItakehiko.noz...@gmail.com
2010/3/7 Christos Zoulas chris...@zoulas.com:
On Mar 7, 5:24am, takehiko.noz...@gmail.com (Takehiko NOZAKI) wrote:
-- Subject: Re: CVS commit: src/lib
