Mail Archives: djgpp-workers/2004/12/30/01:40:27
Hi Martin,
>Then I recompiled the setlocal.c file with "gcc -Wall -g -DTEST" to
>get a test program. Just running it seems to be ok and it reports
>"Locale: sv_SE.850", a map of characters (which I only lightly
>inspected), a collate table (not verified) and a number and date/time
>format. Then I tried with "setlocal C" and it seems ok too (again no
>deep analysis). Then I tried "setlocal en", "setlocal rubbish",
>"setlocal sv" and "setlocal sv_SE" and the program displays reasonable
>things, except maybe for the collate table. In these cases the collate
>table is all zeroes.
That's bad, collate table should not be all zeroes. Which OS you running on?
I will try to review Brian's changes and provide updated liblocal.
>Perhaps it is the right thing to do. But I wanted to ask. And I
>thought (may very well be completely wrong) that locales may be
>abbrevated, like instead of using "sv_SE.850" I may use "sv_SE" or
>"sv" which would use an approximate collate table, which then may be
>further be qualified.
The supported locales are in the _loc2id table (I don't remember what
was the source of this table, more likely it is based on Ralf Brown's
Interrupt List) with the exception of the codepage which is followed
after dot. I.e. you may use "sv_SE" and "sv_SE.850", but not "sv".
From the other side, all tested country.sys drivers did not allowed
me to access data for the locales different for the set in config.sys
(or somewhere in the registry in Windows), so setting locale to "en_US"
will normally fail if your computer set to Swedish locale.
>Should there be some changes to setlocal.txh?
liblocal (at least version 0.2) contains corrected setlocal.txh.
>Is there a more complete test program for tests/...?
It's hard to provide that code since it should be different for the
different locales. The one idea is to generate all possible locales
and verify only "C", "POSIX", default (by returning name and compare
to file) and something odd.
--
Alexander Aganichev
- Raw text -