threads which were created, doing some random mallocs in between
so that threads are not equidistant in the address space
(bug fixed in libpthread/pthread.c rev. 1.109)
versions live in tests/crypto/libcrypto.
Note that the "threads" test is still left here because it was not converted
as part of the atfify GSoC 2008 project. A quick attempt at building it
doesn't work, so I'll leave it for later.
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.
o If a long option looks like an ambiguous abbreviation of two or more long
options, but all the possible interpretations would return the same
value, then just return that value without complaining that it's
ambiguous.
o If a long option could be interpreted either as an exact match for one
long option, or as an abbreviation for one or more other long options,
then treat it as the exact match.
These changes align NetBSD's getopt_long(3) with the current behavior of
GNU getopt_long(3), the de facto standard, and FreeBSD's getopt_long(3).
christos