data and which LC_MONETARY and LC_NUMERIC values it is derived from.
In newlocale(3) and setlocale(3), check for the existing entries and on
miss, create a new entry. This is currently not using a lock for the
list as the worst case is a small memory leak.
Remove the various Current pointers, they are implementation internals
that shouldn't be leaked. Remove _CATEGORY_DEFAULT related handling and
directly pick the implemenation pointer from the C locale.
Merge the C locale data into global_locale.c with the exception of
_DefaultRuneLocale. Mark that one hidden. Move _RUNE_LOCALE and
_CITRUS_CTYPE into multibyte.h and pick up the correct rl_citrus_ctype
for non-default locales.
- turn lint -w for all the platforms after fixing the lint warnings.
- add _DIAGASSERTS() for casts that would assign values to types that
would not fit.
- change types, add casts
- change into ansii prototypes
- turn on _DIAGNOSTIC for libc (during current, to be eliminated for release
builds)
approved by core@
and remove renameing _Rune* -> _NBRune* namespace protection.
FreeBSD traditionaly exposes struct _Rune* in runetype.h
which included by ctype.h. it may cause conflicting type error
in our cross build process, former we use renaming namespace
to avoid this problem, now i reworked more resonable way.
2. merge rune_local.h to runetype_local.h, and remove it.
3. split bsdctype.h -> bsdctype_{file,local}.h
2. unfortunately hppa's MB_LEN_MAX is defined incorrectly 6 instead of 32
so we have to add more setlocale(3) __RENAME func, __setlocale50.
3. move setlocale1.c and setlocale32.c to lib/libc/compat/locale/*
prepareing for next libc major crunk.
4. bump libc minor version.
patch provided by tshiozak@ -san.
2. don't eat 0xfeff/0xfffe if they don't appear at the first of bytestream.
noticed y tshiozak@ -san, patch provied by me.
thanks a lot.
statically initialized _DefaultRuneLocale.rl_wctrans field.
so we can re-const-ify _DefaultRuneLocale.
pkgsrc/shells/standalone-tcsh should be rebuild,
because it's staticaly linked binary.
ok'ed by core and releng.
(thanks for agc@, snj@ and i'm sorry for long time patience).
[libc]
- localeio.[ch] and lc*.[ch] in src/lib/libc/locale was replaced by
new locale-db implementation using citrus_db backend,
see src/lib/libc/citrus/citrus_lc_*.[ch].
- add citrus_bcs_strtou?l.c. don't use strtou?l locale implementation
internally, because they're locale-aware function.
- add some stubs for multi-locale issue, see {current,global}_locale.c.
- remove some obsolete file, setrunelocale.c, ___runetype_mb.c.
- remove __savectype() from ctypeio.[ch].
[tools]
- mklocale(1): add new option ``-t'' that generates new style
LC_{MONETARY,NUMERIC,TIME,MESSAGES} locale-db format.
- chrtbl(1): added ctypeio.[ch] for __savectype().
[locale-db]
- added en_US.US-ASCII locale.
- removed some shareable locale definition file:
en_US.US-ASCII -> en_US.ISO8859-1, en_US.UTF-8
zh_CN.eucCN -> zh_CN.GB18030
and more...see src/share/locale/*/Makefile.
- remove obsoleted locale sr_YU, added new locale sr_ME, sr_RS.
- change locale name ja_JP.ISO2022-JP* -> ja_JP.ISO-2022-JP*
for X11's locale.alias file alignments.
- fix regression test, wrong wcs?width(3), NAN/INF usage.
i tested release-build following arch:
i386, amd64, hpc{mips,arm,sh}, sparc64, vax.
citrus_lc_*.[ch] also can read old-plain-text style locale-db.
so that backward compatibility is keeped, but lc*.[ch] can't read
new citrus_db'ed locale-db and localeio.c never check sanity,
so forward compatibility is broken ;-<
old mklocale(1) doesn't know -t option, so you have to rebuild toolchain.
