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".
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
