the tests must work in various environment, opensolaris being one of them
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

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)
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 }

On Tue, 27 Jul 2010 00:24:11 +0200 Roland Mainz wrote:
> On Mon, Jul 26, 2010 at 10:29 PM, Glenn Fowler <[email protected]> wrote:
> >
> > On Mon, 26 Jul 2010 22:16:08 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= 
> > wrote:
> >> Glenn, can a caller of shtests still override LC_ALL/LANG?
> >
> > not as it stands now
> >
> > the idea is C locale is the default for all test writers
> > tests exercising locale-specific features should set the locale in the test 
> > script
> > because of the default, allowing shtests to override it may invalidate some 
> > tests

> Erm... I have very strong concerns about this change.
> Until now we (=the OpenSolaris ksh93-integration project) assumed that
> the "shtests" frontend resets the LANG variable to "C" (we do this
> additionally externally and unset all LC_* variables) and that we can
> override this with any locale which is a superset of the ASCII
> encoding and has the decimal delimiter set to '.' (in OpenSolaris one
> of the basic test procedures is to iterate over all locales reported
> by $ locale =a # which have the decimal delimiter set to '.' ... this
> takes a long time but helps a lot to keep the quality at a very good
> level).
> This helped a lot in the past digging out problems (either in the
> ksh93/AST codebase or in the Solaris i18n code) in other locales, for
> example the multibyte locales which often have seperate codepaths from
> the single-byte locales.

> However... if this gets changed and all modules use "C" by default we
> loose the abilty and the tests will cover _much_ less ground and code
> than we currently do.

> IMO a better solution would be to unset all LC_* variables in
> "shtests", set LANG='C', allow the caller  of "shtests" to override
> _any_ LC_*/LANG variable and let the individual test modules use
> LC_MESSAGES or LC_ALL if they rely on a specific message output or
> locale.

> ----

> 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

Reply via email to