some of the ksh93 (and ast) locale-specific regression tests are for
testing the ast implementation and not the native locale implementation
to ensure that we are testing only ast code some regression tests
may use ast specific "debug" and/or "C.UTF-8" locales only
if other users want to test native locale implementations they are free to do so
and we welcome feedback for any ksh/ast problems that may surface
shtests provides an option to accecpt the caller locale
and that locale will be honored for all tests except those specifically
designed to use the ast specific locales
this is a way for us to maintain sanity
the ksh93 tests that use ast specific locales are
io.sh 1 subtest, all others use caller locale
locale.sh all subtests
substring.sh 12 subtests
if you want the native implementation exercised for these then they will
have to be copied and re-coded with the native implementation in mind
re: other mb encodings -- the locale specific tests are geared towards
locales that we have access to (and experience with) -- if anyone has
locale specific tests we can integrate them into locale.sh with probes
to make sure the locale is supported on the host running the tests
On Mon, 2 Aug 2010 03:59:51 +0200 Roland Mainz wrote:
> On Tue, Jul 27, 2010 at 8:25 AM, Glenn Fowler <[email protected]> wrote:
> >
> > the tests must work in various environment, opensolaris being one of them
> I know that much more platforms must be covered. I tried to say that
> we're one of those platform which runs the "shtests" with more than
> just the "C" locale to make sure we meet the Solaris quality
> requirements.
> > from the ast standpoint
> > nmake test
> > must work for all users and all ast packages
> > in order to make this work the ast test harnesses set up a common
> > controlled environment
> > test writers expect that commmon controlled environment
> > deviations from the controlled environment could have unexpected test
> > consequences
> >
> > I added { -l --locale-accept } options to ksh93/tests/shtests
> > with -l set { LANG LC_ALL } are inherited from the caller
> > this may cause false positives for some tests
> > but those are the responsibility of the caller who used -l
> Thanks...
> ... but AFAIK it may be better to just unset all LC_* variables and
> LANG and set explicitly LANG="C" and keep the old way of defining
> extra environment variables via $ shtests <options> var1=value1
> var2=value2 ... <testmodule.sh> #
> > you raise a good point about different codepaths for C vs multibyte locale
> > we added an ast specific testing locale C.UTF-8 that could be used
> > to exercise the different codepaths, but in a controlled way since
> > C.UTF-8 has the same implementation on all systems
> > (not good for debugging locale implementations, but the ast regression
> > tests are mainly for testing ast implementations)
> Erm... Ok... but there are some problems:
> 1. There are more _modern_ locales which use a non-UTf-8 encoding. For
> example one is GB18030 which is _required_ by the Chinese goverment
> (usually by the style of "you do not get _any_ goverment contract
> without supporting GB18030").
> 2. There are encodings which are still commonly in use which are not
> UTF-8 either not can they represent the full range of Unicode
> characters (I won't call them "legacy" because it quickly results in a
> political hell like "you've offended our cultural heirloom")
> 3. IMO neither "shtests" nor the test modules should hardcode
> "C"+"C.UTF-8", otherwise the tests can never be used to test the
> affected codepaths with other locales (as said a while ago this
> ability proved very usefull... there were lots of nasty bugs in
> zh_CN.GB18030 which were found, trialled&&executed by quartering)
> IMHO the best solution may be:
> Keep "shtests" as it was in ksh93t+ except that it should unset the
> LC_* variables and LANG, then set LANG="C" and let the caller of
> "shtests" override any environment variable. On demand LANG should be
> used to define an alternative locale. The $ nmake test # code is then
> responsible to make two "shtests" runs, one with "C" and one with
> "C.UTF-8". Individual test modules should only override LANG/LC_* if
> absolutely neccesary.
> > so
> > similar to shtests running with various VMALLOC_OPTIONS by default,
> > I'll look at running with LC_ALL = { C C.UTF-8 } for tests that don't
> > specifically reference { LANG LC_ALL }
> Mhhh... see above... IMO it would be good if LANG used by "shtests" is
> defined _outside_ "shtests".
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
