[stlport-bugs] [ stlport-Bugs-1704843 ] bug in _M_seek() when using STDIO I/O

[SourceForge.net <noreply@so...>]

Bugs item #1704843, was opened at 2007-04-21 15:36
Message generated for change (Comment added) made by polo78
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1704843&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Operational Environment/Compiler specific code
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Marco Jez (polo78)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in _M_seek() when using STDIO I/O

Initial Comment:
I'm porting latest STLport to Symbian OS and I'm getting a failure in the FstreamTest::tellg test. I think I've tracked down the problem to a possible bug in _Filebuf_base::_M_seek() that only occurs when _STLP_USE_STDIO_IO is enabled. 

In a nutshell, the call to fseek() treats the return value as if it were a stream offset, while actually it is a flag that only indicates success or failure. This misinterpretation of the return value makes the function always return zero (as long as fseek() succedes).

I've temporarily corrected this bug by calling ftell() after fseek() and returning the value returned by ftell() instead. This makes the unit test pass.

I'm new to STLport, so please discard this request if it's not a bug.


----------------------------------------------------------------------

>Comment By: Marco Jez (polo78)
Date: 2007-04-24 13:57

Message:
Logged In: YES 
user_id=649549
Originator: YES

Ok, I'll make a patch once my porting is complete (in case I spot other
bugs).

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-04-23 10:41

Message:
Logged In: YES 
user_id=615813
Originator: NO

Because Marco post answer here:
https://sourceforge.net/forum/message.php?msg_id=4274183,
I cite it in original place, to track issue.

<snip>

STLPORT VERSION: 
5.1.3 
 
PLATFORM #1: 
Symbian OS 9.1 
compiler: GCCE (GCC version for ARM, version 3.4.3)  
 
PLATFORM #2: 
Win32 (emulator for Symbian devices) 
compiler: WINSCW (a CodeWarrior derivative, version 3.2.5) 
 
STANDARD C LIBRARY: 
Nokia's OpenC 
 
CONFIGURATION OPTIONS THAT TRIGGER THE BUG: 
_STLP_USE_STDIO_IO is defined 
(other options don't affect the offending code) 
 
PROBLEM: 
the FstreamTest::tellg test fails on assertion ( is.tellg() == p ); 
 
INVESTIGATION: 
tellg() fails because the _Filebuf_base::_M_seek() function has incorrect
behaviour when _STLP_USE_STDIO_IO is in effect: 
 
 streamoff _Filebuf_base::_M_seek(streamoff offset, ios_base::seekdir dir)
{ 
 ... 
 ... 
 #elif defined (_STLP_USE_STDIO_IO) 
 
 result = fseek(_M_file, offset, whence); 
 
 #elif defined (_STLP_USE_WIN32_IO) 
 ... 
 ... 
 return result; 
 } 
 
 
(code is in src/fstream.cpp, around line 1022) 
 
as shown above, the _M_seek() function returns the value returned by
fseek() as if it were the new stream position. This is wrong: the fseek()
function doesn't return a position, it returns a boolean flag (0 = success,
nonzero = failure). As a result, during the unit test the _M_seek()
function always return zero, hence the test fails. 
 
If it is relevant I can post the whole platform-dependent configuration,
but I think the code is pretty clear. 
 
Cheers, 
Marco 
</snip>

----------------------------------------------------------------------

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2007-04-23 09:45

Message:
Logged In: YES 
user_id=1522877
Originator: NO

Yep, it's a bug and I guess that your fix is even correct, i.e. check the
returnvalue for 0/-1 and then either return the result of ftell() or
streamoff(-1). Also check the returnvalue of ftell(). Could you submit a
patch?

FYI: if you wonder why this wasn't caught, the reason is that on Unix-like
systems we use filedescriptors instead of C's FILE IO and on MS Windows
systems we use their specific IO functions, both because the FILE IO is
just a wrapper around the native IO style anyways. This leaves pretty few
systems and those are rather little-tested. Anyway, if Symbian OS has
another native IO style, you might consider using that, too, in a later
step.

BTW: I checked all other uses of fseek() and there is only one place left
in the MS Windows CE implementation that looks dubious - it doesn't even
look at the returnvalue there.

cheers

Uli


----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-04-22 07:00

Message:
Logged In: YES 
user_id=615813
Originator: NO

http://stlport.sourceforge.net/BugReport.shtml

Without code sample and INITIAL problem description, we can't discuss
this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1704843&group_id=146814

[stlport-bugs] [ stlport-Bugs-1704843 ] bug in _M_seek() when using STDIO I/O

[SourceForge.net <noreply@so...>]

Bugs item #1704843, was opened at 2007-04-21 17:36
Message generated for change (Comment added) made by complement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1704843&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Operational Environment/Compiler specific code
Group: None
>Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Marco Jez (polo78)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in _M_seek() when using STDIO I/O

Initial Comment:
I'm porting latest STLport to Symbian OS and I'm getting a failure in the FstreamTest::tellg test. I think I've tracked down the problem to a possible bug in _Filebuf_base::_M_seek() that only occurs when _STLP_USE_STDIO_IO is enabled. 

In a nutshell, the call to fseek() treats the return value as if it were a stream offset, while actually it is a flag that only indicates success or failure. This misinterpretation of the return value makes the function always return zero (as long as fseek() succedes).

I've temporarily corrected this bug by calling ftell() after fseek() and returning the value returned by ftell() instead. This makes the unit test pass.

I'm new to STLport, so please discard this request if it's not a bug.


----------------------------------------------------------------------

>Comment By: Petr Ovtchenkov (complement)
Date: 2007-04-23 12:41

Message:
Logged In: YES 
user_id=615813
Originator: NO

Because Marco post answer here:
https://sourceforge.net/forum/message.php?msg_id=4274183,
I cite it in original place, to track issue.

<snip>

STLPORT VERSION: 
5.1.3 
 
PLATFORM #1: 
Symbian OS 9.1 
compiler: GCCE (GCC version for ARM, version 3.4.3)  
 
PLATFORM #2: 
Win32 (emulator for Symbian devices) 
compiler: WINSCW (a CodeWarrior derivative, version 3.2.5) 
 
STANDARD C LIBRARY: 
Nokia's OpenC 
 
CONFIGURATION OPTIONS THAT TRIGGER THE BUG: 
_STLP_USE_STDIO_IO is defined 
(other options don't affect the offending code) 
 
PROBLEM: 
the FstreamTest::tellg test fails on assertion ( is.tellg() == p ); 
 
INVESTIGATION: 
tellg() fails because the _Filebuf_base::_M_seek() function has incorrect
behaviour when _STLP_USE_STDIO_IO is in effect: 
 
 streamoff _Filebuf_base::_M_seek(streamoff offset, ios_base::seekdir dir)
{ 
 ... 
 ... 
 #elif defined (_STLP_USE_STDIO_IO) 
 
 result = fseek(_M_file, offset, whence); 
 
 #elif defined (_STLP_USE_WIN32_IO) 
 ... 
 ... 
 return result; 
 } 
 
 
(code is in src/fstream.cpp, around line 1022) 
 
as shown above, the _M_seek() function returns the value returned by
fseek() as if it were the new stream position. This is wrong: the fseek()
function doesn't return a position, it returns a boolean flag (0 = success,
nonzero = failure). As a result, during the unit test the _M_seek()
function always return zero, hence the test fails. 
 
If it is relevant I can post the whole platform-dependent configuration,
but I think the code is pretty clear. 
 
Cheers, 
Marco 
</snip>

----------------------------------------------------------------------

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2007-04-23 11:45

Message:
Logged In: YES 
user_id=1522877
Originator: NO

Yep, it's a bug and I guess that your fix is even correct, i.e. check the
returnvalue for 0/-1 and then either return the result of ftell() or
streamoff(-1). Also check the returnvalue of ftell(). Could you submit a
patch?

FYI: if you wonder why this wasn't caught, the reason is that on Unix-like
systems we use filedescriptors instead of C's FILE IO and on MS Windows
systems we use their specific IO functions, both because the FILE IO is
just a wrapper around the native IO style anyways. This leaves pretty few
systems and those are rather little-tested. Anyway, if Symbian OS has
another native IO style, you might consider using that, too, in a later
step.

BTW: I checked all other uses of fseek() and there is only one place left
in the MS Windows CE implementation that looks dubious - it doesn't even
look at the returnvalue there.

cheers

Uli


----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-04-22 09:00

Message:
Logged In: YES 
user_id=615813
Originator: NO

http://stlport.sourceforge.net/BugReport.shtml

Without code sample and INITIAL problem description, we can't discuss
this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1704843&group_id=146814

[stlport-bugs] [ stlport-Bugs-1704843 ] bug in _M_seek() when using STDIO I/O

[SourceForge.net <noreply@so...>]

Bugs item #1704843, was opened at 2007-04-21 15:36
Message generated for change (Comment added) made by eckhardt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1704843&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Operational Environment/Compiler specific code
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Marco Jez (polo78)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in _M_seek() when using STDIO I/O

Initial Comment:
I'm porting latest STLport to Symbian OS and I'm getting a failure in the FstreamTest::tellg test. I think I've tracked down the problem to a possible bug in _Filebuf_base::_M_seek() that only occurs when _STLP_USE_STDIO_IO is enabled. 

In a nutshell, the call to fseek() treats the return value as if it were a stream offset, while actually it is a flag that only indicates success or failure. This misinterpretation of the return value makes the function always return zero (as long as fseek() succedes).

I've temporarily corrected this bug by calling ftell() after fseek() and returning the value returned by ftell() instead. This makes the unit test pass.

I'm new to STLport, so please discard this request if it's not a bug.


----------------------------------------------------------------------

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2007-04-23 09:45

Message:
Logged In: YES 
user_id=1522877
Originator: NO

Yep, it's a bug and I guess that your fix is even correct, i.e. check the
returnvalue for 0/-1 and then either return the result of ftell() or
streamoff(-1). Also check the returnvalue of ftell(). Could you submit a
patch?

FYI: if you wonder why this wasn't caught, the reason is that on Unix-like
systems we use filedescriptors instead of C's FILE IO and on MS Windows
systems we use their specific IO functions, both because the FILE IO is
just a wrapper around the native IO style anyways. This leaves pretty few
systems and those are rather little-tested. Anyway, if Symbian OS has
another native IO style, you might consider using that, too, in a later
step.

BTW: I checked all other uses of fseek() and there is only one place left
in the MS Windows CE implementation that looks dubious - it doesn't even
look at the returnvalue there.

cheers

Uli


----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-04-22 07:00

Message:
Logged In: YES 
user_id=615813
Originator: NO

http://stlport.sourceforge.net/BugReport.shtml

Without code sample and INITIAL problem description, we can't discuss
this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1704843&group_id=146814

[stlport-bugs] [ stlport-Bugs-1704843 ] bug in _M_seek() when using STDIO I/O

[SourceForge.net <noreply@so...>]

Bugs item #1704843, was opened at 2007-04-21 17:36
Message generated for change (Comment added) made by complement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1704843&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Operational Environment/Compiler specific code
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Marco Jez (polo78)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in _M_seek() when using STDIO I/O

Initial Comment:
I'm porting latest STLport to Symbian OS and I'm getting a failure in the FstreamTest::tellg test. I think I've tracked down the problem to a possible bug in _Filebuf_base::_M_seek() that only occurs when _STLP_USE_STDIO_IO is enabled. 

In a nutshell, the call to fseek() treats the return value as if it were a stream offset, while actually it is a flag that only indicates success or failure. This misinterpretation of the return value makes the function always return zero (as long as fseek() succedes).

I've temporarily corrected this bug by calling ftell() after fseek() and returning the value returned by ftell() instead. This makes the unit test pass.

I'm new to STLport, so please discard this request if it's not a bug.


----------------------------------------------------------------------

>Comment By: Petr Ovtchenkov (complement)
Date: 2007-04-22 09:00

Message:
Logged In: YES 
user_id=615813
Originator: NO

http://stlport.sourceforge.net/BugReport.shtml

Without code sample and INITIAL problem description, we can't discuss
this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1704843&group_id=146814

[stlport-bugs] [ stlport-Bugs-1704843 ] bug in _M_seek() when using STDIO I/O

[SourceForge.net <noreply@so...>]

Bugs item #1704843, was opened at 2007-04-21 15:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1704843&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Operational Environment/Compiler specific code
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marco Jez (polo78)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in _M_seek() when using STDIO I/O

Initial Comment:
I'm porting latest STLport to Symbian OS and I'm getting a failure in the FstreamTest::tellg test. I think I've tracked down the problem to a possible bug in _Filebuf_base::_M_seek() that only occurs when _STLP_USE_STDIO_IO is enabled. 

In a nutshell, the call to fseek() treats the return value as if it were a stream offset, while actually it is a flag that only indicates success or failure. This misinterpretation of the return value makes the function always return zero (as long as fseek() succedes).

I've temporarily corrected this bug by calling ftell() after fseek() and returning the value returned by ftell() instead. This makes the unit test pass.

I'm new to STLport, so please discard this request if it's not a bug.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1704843&group_id=146814

[stlport-bugs] [ stlport-Bugs-1699349 ] Wrong file name libstlport.so.5.1.1

[SourceForge.net <noreply@so...>]

Bugs item #1699349, was opened at 2007-04-12 17:23
Message generated for change (Comment added) made by dums
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1699349&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build system
Group: 5.0
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Andy_U (andy_u)
>Assigned to: Francois Dumont (dums)
Summary: Wrong file name libstlport.so.5.1.1

Initial Comment:
In the file STLport-5.1.3\build\lib\Makefile.inc (line 6 ) there is an assignment of 1 to variable PATCH: 

PATCH = 1

which results in wrong shared library name  libstlport.so.5.1.1. Please change 1 to 3:

PATCH = 3

Thank you.

----------------------------------------------------------------------

>Comment By: Francois Dumont (dums)
Date: 2007-04-20 22:30

Message:
Logged In: YES 
user_id=1096600
Originator: NO

Sorry for the inconvenience, I have updated tarballs of the release with
the right patch value.

Bests


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1699349&group_id=146814

[stlport-bugs] [ stlport-Bugs-1699349 ] Wrong file name libstlport.so.5.1.1

[SourceForge.net <noreply@so...>]

Bugs item #1699349, was opened at 2007-04-12 19:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1699349&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build system
Group: 5.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andy_U (andy_u)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong file name libstlport.so.5.1.1

Initial Comment:
In the file STLport-5.1.3\build\lib\Makefile.inc (line 6 ) there is an assignment of 1 to variable PATCH: 

PATCH = 1

which results in wrong shared library name  libstlport.so.5.1.1. Please change 1 to 3:

PATCH = 3

Thank you.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1699349&group_id=146814

[stlport-bugs] [ stlport-Bugs-1634886 ] wrong russian currency name in unittests

[SourceForge.net <noreply@so...>]

Bugs item #1634886, was opened at 2007-01-13 22:17
Message generated for change (Settings changed) made by dums
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1634886&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Tiziano Müller (tizianomueller)
Assigned to: Petr Ovtchenkov (complement)
Summary: wrong russian currency name in unittests

Initial Comment:
In test/unit/locale_test.cpp is "RUR" written as the russian currency name. This should be "RUB" according to my glibc and http://en.wikipedia.org/wiki/ISO_4217#Active_codes_.28sorted_by_code.29


----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-04-01 22:03

Message:
Logged In: YES 
user_id=1096600
Originator: NO

You took it the wrong way, this bug, even if it is not really a bug, has
only be fixed in SVN trunk and not in STLPORT_5_1 branch. So this hasn't
show up again, it has simply never disappear from 5.1.x. But this is such a
small modification that I will surely put it in 5.1 branch.

----------------------------------------------------------------------

Comment By: Tiziano Müller (tizianomueller)
Date: 2007-04-01 13:05

Message:
Logged In: YES 
user_id=935305
Originator: YES

Great, this shows up in 5.1.2 again. I put cout's in the code to print
them.
[...]
LocaleTest::money_put_get
        fr_FR  str_res.substr(index, p): EUR
  rl.money_int_prefix: EUR
  p_old: 4
  str_res.substr(index, p_old): EUR
  rl.money_int_prefix_old:FRF

        ru_RU.koi8r  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        en_GB  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        en_US  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        C
LocaleTest::money_put_X_bug
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::time_put_get
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::collate_facet
LocaleTest::ctype_facet
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::locale_init_problem
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
        combining 'ru_RU.koi8r' money facets with 'fr_FR' 
str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): EUR
  rl.money_int_prefix: EUR
  p_old: 4
  str_res.substr(index, p_old): EUR
  rl.money_int_prefix_old:FRF
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): EUR
  rl.money_int_prefix: EUR
  p_old: 4
  str_res.substr(index, p_old): EUR
  rl.money_int_prefix_old:FRF
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        combining 'en_GB' money facets with 'ru_RU.koi8r' 
str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        combining 'en_US' money facets with 'en_GB'  str_res.substr(index,
p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        combining 'C' money facets with 'en_US'  str_res.substr(index, p):
USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
[...]

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-16 08:21

Message:
Logged In: YES 
user_id=615813
Originator: NO

My inadvertence, tests fine. Francois' fix good. Resolved.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-16 02:44

Message:
Logged In: YES 
user_id=615813
Originator: NO

BTW, see the second table in initial ref.

Seeing on this I found problem with unit tests---investigating.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-16 00:49

Message:
Logged In: YES 
user_id=615813
Originator: NO

Not all so good. glibc 2.3.6 and before has RUR here, while glibc 2.5
already has correct RUB. Something between this.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-15 21:45

Message:
Logged In: YES 
user_id=1096600
Originator: NO

Fixed in SVN trunk, thanks for the report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1634886&group_id=146814

[stlport-bugs] [ stlport-Bugs-1634886 ] wrong russian currency name in unittests

[SourceForge.net <noreply@so...>]

Bugs item #1634886, was opened at 2007-01-13 22:17
Message generated for change (Comment added) made by dums
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1634886&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Tiziano Müller (tizianomueller)
Assigned to: Petr Ovtchenkov (complement)
Summary: wrong russian currency name in unittests

Initial Comment:
In test/unit/locale_test.cpp is "RUR" written as the russian currency name. This should be "RUB" according to my glibc and http://en.wikipedia.org/wiki/ISO_4217#Active_codes_.28sorted_by_code.29


----------------------------------------------------------------------

>Comment By: Francois Dumont (dums)
Date: 2007-04-01 22:03

Message:
Logged In: YES 
user_id=1096600
Originator: NO

You took it the wrong way, this bug, even if it is not really a bug, has
only be fixed in SVN trunk and not in STLPORT_5_1 branch. So this hasn't
show up again, it has simply never disappear from 5.1.x. But this is such a
small modification that I will surely put it in 5.1 branch.

----------------------------------------------------------------------

Comment By: Tiziano Müller (tizianomueller)
Date: 2007-04-01 13:05

Message:
Logged In: YES 
user_id=935305
Originator: YES

Great, this shows up in 5.1.2 again. I put cout's in the code to print
them.
[...]
LocaleTest::money_put_get
        fr_FR  str_res.substr(index, p): EUR
  rl.money_int_prefix: EUR
  p_old: 4
  str_res.substr(index, p_old): EUR
  rl.money_int_prefix_old:FRF

        ru_RU.koi8r  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        en_GB  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        en_US  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        C
LocaleTest::money_put_X_bug
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::time_put_get
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::collate_facet
LocaleTest::ctype_facet
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::locale_init_problem
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
        combining 'ru_RU.koi8r' money facets with 'fr_FR' 
str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): EUR
  rl.money_int_prefix: EUR
  p_old: 4
  str_res.substr(index, p_old): EUR
  rl.money_int_prefix_old:FRF
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): EUR
  rl.money_int_prefix: EUR
  p_old: 4
  str_res.substr(index, p_old): EUR
  rl.money_int_prefix_old:FRF
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        combining 'en_GB' money facets with 'ru_RU.koi8r' 
str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        combining 'en_US' money facets with 'en_GB'  str_res.substr(index,
p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        combining 'C' money facets with 'en_US'  str_res.substr(index, p):
USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
[...]

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-16 08:21

Message:
Logged In: YES 
user_id=615813
Originator: NO

My inadvertence, tests fine. Francois' fix good. Resolved.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-16 02:44

Message:
Logged In: YES 
user_id=615813
Originator: NO

BTW, see the second table in initial ref.

Seeing on this I found problem with unit tests---investigating.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-16 00:49

Message:
Logged In: YES 
user_id=615813
Originator: NO

Not all so good. glibc 2.3.6 and before has RUR here, while glibc 2.5
already has correct RUB. Something between this.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-15 21:45

Message:
Logged In: YES 
user_id=1096600
Originator: NO

Fixed in SVN trunk, thanks for the report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1634886&group_id=146814

[stlport-bugs] [ stlport-Bugs-1670439 ] some locale tests fail in 5.1.1/2 under MSVC8 with Boost

[SourceForge.net <noreply@so...>]

Bugs item #1670439, was opened at 2007-02-28 03:48
Message generated for change (Comment added) made by complement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1670439&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Alex Tartakovsky (tartak)
>Assigned to: Petr Ovtchenkov (complement)
Summary: some locale tests fail in 5.1.1/2 under MSVC8 with Boost

Initial Comment:
8 tests failed (out of 383). All 8 are in LocaleTest.
Build under VStudio 2005 (SP1) with Boost 1.33.1
Output:
===============
LocaleTest::locale_by_name
LocaleTest::loc_has_facet
LocaleTest::num_put_get
	fr_FR
	en_GB
	en_US
	C
LocaleTest::money_put_get
	fr_FR
	en_GB

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	en_US
	C
LocaleTest::money_put_X_bug
	fr_FR
	en_GB

../../../test/unit\locale_test.cpp(419) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	en_US
	C
LocaleTest::time_put_get
	fr_FR
	en_GB
	en_US
	C
LocaleTest::collate_facet
LocaleTest::ctype_facet
	fr_FR
	en_GB
	en_US
	C
LocaleTest::locale_init_problem
	fr_FR
	en_GB
	en_US
	C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
	combining 'en_GB' money facets with 'fr_FR'

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	combining 'en_US' money facets with 'en_GB'

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	combining 'C' money facets with 'en_US'

----------------------------------------------------------------------

>Comment By: Petr Ovtchenkov (complement)
Date: 2007-04-01 17:41

Message:
Logged In: YES 
user_id=615813
Originator: NO

Not confirmed, as in trunk as in 5_1 branch. Don't mix Linux builds and
MSVC, especially in such system-dependand issue as locale.

----------------------------------------------------------------------

Comment By: Tiziano Müller (tizianomueller)
Date: 2007-04-01 15:03

Message:
Logged In: YES 
user_id=935305
Originator: NO

I'm wrong, sorry. It's not the same bug.

----------------------------------------------------------------------

Comment By: Tiziano Müller (tizianomueller)
Date: 2007-04-01 14:34

Message:
Logged In: YES 
user_id=935305
Originator: NO

It's not MSVC or Windows related. I get the same errors on Linux
(glibc-2.5, x86 or ppc) with gcc-4.1.2:

LocaleTest::num_put_get
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::money_put_get
        fr_FR
        ru_RU.koi8r

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        en_GB
        en_US
        C
LocaleTest::money_put_X_bug
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::time_put_get
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::collate_facet
LocaleTest::ctype_facet
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::locale_init_problem
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
        combining 'ru_RU.koi8r' money facets with 'fr_FR'

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        combining 'en_GB' money facets with 'ru_RU.koi8r'

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        combining 'en_US' money facets with 'en_GB'
        combining 'C' money facets with 'en_US'


----------------------------------------------------------------------

Comment By: archimed7592 (archimed7592)
Date: 2007-03-20 11:06

Message:
Logged In: YES 
user_id=1747018
Originator: NO

> Here is what I do, so you can reproduce it.

I had reproduced it (mingw without boost). no effect. my 8/12 errors
kept.


I have another question: in which cases it will affect my programs (sample
code, please). I doubt, I will never use this features.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-03-09 22:38

Message:
Logged In: YES 
user_id=615813
Originator: NO

> Here is what I do, so you can reproduce it

Well, I can't: I have no Wins.

CP866, CP437, etc. --- is a DOS hangover. Looks like CP437 has pound sign,
you can check. But, of cause, it absent in CP866. So, I treat, that this OE
can't provide appropriate locale support.

> I think the test should check the
code page or, at least, warn the user to switch to the proper code page -
the one needed for the test to succeed

No. This test shouldn't do this. The test fail is signal that you have OE
with restricted support of locale, without respect how you achieve it. Not
more. Use this knowledge your own discretion. 

----------------------------------------------------------------------

Comment By: Alex Tartakovsky (tartak)
Date: 2007-03-09 22:00

Message:
Logged In: YES 
user_id=1331880
Originator: YES

Petr, what you describe is not what I do.  I use locale settings expressly
supported by OS, and documented by MS as such.  

Here is what I do, so you can reproduce it. I don't actually change the
codepage directly. I set up my locale settings (which indirectly changes
the codepage) in Control Panel/Regional and Language Options. I go to
Advanced tab there and select the "Language for non-Unicode Programs". I
change it from the default English(US) to Russian. This should not affect
Unicode programs. I need it simply because I have a few non-Unicode
programs where I want to be able to type in some text in Russian - they
would not show the text otherwise. By the way, on the same tab there is a
list of code page conversion tables installed on my computer: the ones you
mentioned, 1250-1252 are installed among many others, and I don't make any
changes there.

Now, when I change the language as described above, and then issue "chcp"
(without a parameter) command in console, I get 866. If I switch the
language back (using the same procedure) to English(US), chcp in console
gives me 437. 

According to MS Windows documentation of chcp, it shows the active console
code page. That code page is obviously what's the tests are run under.  The
documentation lists the supported code pages, here is the complete list
copied from there:

Code page Country/region or language 
437 United States 
850 Multilingual (Latin I) 
852 Slavic (Latin II) 
855 Cyrillic (Russian) 
857 Turkish 
860 Portuguese 
861 Icelandic 
863 Canadian-French 
865 Nordic 
866 Russian 
869 Modern Greek 

As you see, there is nothing outdated about 437 or 866. 437 is the
default, and 866 is supported.  All those 125x code pages are not on the
list for console.

It may very well be that there is absolutely nothing wrong with STLport,
and the problem is with the test itself. From the above, it appears clear
that, on a standard US Win XP installation, the console tests are run under
code page 437.  But the code page may be switched (even without user's
knowledge) to one of the listed above. I think the test should check the
code page or, at least, warn the user to switch to the proper code page -
the one needed for the test to succeed.

Regards, 
Lesha

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-03-09 15:27

Message:
Logged In: YES 
user_id=615813
Originator: NO

In POSIX world locale assume both locale settings and charset. You can see
explicit specification of charset: "ru_RU.koi8r". Every locale has
'default' charset, that used when charset not mentioned explicitly. en_GB
assume ISO-8859-1. The pound sterling has code 0xa3 in ISO-8859-1, so we
hardcoded this value and don't worry.

But you use old (DOS) codepages (hehe, under system with native UTF16):
866 and 437 (hmmm, why not CP1251 and CP1250/CP1252?). Or why not give
chance to wins track all encodings via native UTF16?

Really, looks like you made such OE settings that lead to poor locales
support. And tests inform you about this indeed. STLport locales based on
system support for locale, so if system don't support [may be some]
locales, we haven't chances to do work correctly.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-03-09 12:54

Message:
Logged In: YES 
user_id=1096600
Originator: NO

No it is not something expected, it would be great to make this tests more
portable. I will try to play with my system settings to see if I can break
the tests like that and then I will see if forcing code page in
localization string can safe our life.

Bests


----------------------------------------------------------------------

Comment By: Alex Tartakovsky (tartak)
Date: 2007-03-06 22:32

Message:
Logged In: YES 
user_id=1331880
Originator: YES

I tested on Win XP, US version.  But the code page was switched to 866 -
Russian.  It's under 866 that I had those errors in LocalTest.  When I
switch back to the default 437 (US), all tests succeed.  Is it something to
be expected? I mean, the tests do not warn that they must be run under a
specific code page...

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-03-04 22:56

Message:
Logged In: YES 
user_id=1096600
Originator: NO

I think the fact that you are in chinese explain why tests are not working
as expected. Could you try to specify code page in locale name and tell us
if you still have problem. You can do so replacing "fr_FR" with
"fr_FR.1252", idem for "en_EN" and "en_US".

There is a problem in your script, all builds are done configured with
msvc71 (configure -c msvc71). For VC6 and VC8 it should be different,
'configure -c msvc6' and 'configure -c msvc8' respectively.

As you are a chinese user I would like to take the opportunity of asking
you if you are happy with STLport and especially with its localization
support under Windows and Linux. Is it working fine with your language ?
Thanks for help.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-03 17:39

Message:
Logged In: NO 

some UnitTest also failed in STLport SVN(2945) under MSVC71(.Net 2003)
with SP1(KB918007) on Window XP sp2 (Traditional Chinese Version),
and Microsoft (R) Program Maintenance Utility Version 7.10.3077

Output:
=======================
LocaleTest::num_put_get
        fr_FR
        en_GB
        en_US
        C
LocaleTest::money_put_get
        fr_FR

../../../test/unit\locale_test.cpp(243) : CPPUNIT_ASSERT(str_res[index++]
== *rl.money_thousands_sep);
        en_GB

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        en_US
        C
LocaleTest::money_put_X_bug
        fr_FR
        en_GB

../../../test/unit\locale_test.cpp(419) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        en_US
        C
LocaleTest::time_put_get
        fr_FR
        en_GB
        en_US
        C
LocaleTest::collate_facet
LocaleTest::ctype_facet
        fr_FR
        en_GB
        en_US
        C
LocaleTest::locale_init_problem
        fr_FR
        en_GB
        en_US
        C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
        combining 'en_GB' money facets with 'fr_FR'

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(243) : CPPUNIT_ASSERT(str_res[index++]
== *rl.money_thousands_sep);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(243) : CPPUNIT_ASSERT(str_res[index++]
== *rl.money_thousands_sep);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        combining 'en_US' money facets with 'en_GB'

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        combining 'C' money facets with 'en_US'

========================
My build using almost the same batch scripts as followings except some
echo strings and comments are in big5 encoding. The batch scripts was
placed under the directory the same as INSTALL, doc, etc, and lib (i.e. the
root of Stlport package).


=======batch_start=======
@ECHO OFF
:: Was nmake available?
nmake /?
IF %ERRORLEVEL% EQU 0 GOTO START_COMPILE

IF EXIST "%VS80COMNTOOLS%vsvars32.bat" GOTO VC80
IF EXIST "%VS71COMNTOOLS%vsvars32.bat" GOTO VC71
IF EXIST "C:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.bat"
GOTO VC6

:VC6
CALL "C:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.bat"
GOTO START_COMPILE

:VC71
CALL "%VS71COMNTOOLS%vsvars32.bat"
GOTO START_COMPILE

:VC80
CALL "%VS80COMNTOOLS%vsvars32.bat"
GOTO START_COMPILE

:START_COMPILE
CD build\lib
CALL configure.bat --clean
CALL configure.bat -c msvc71 --extra-cxxflag /G7
nmake /f msvc.mak clean all install
cd ..\..\
GOTO END

:ERROR_MSG
ECHO Could not find vcvars32.bat!
GOTO END

:END
@ECHO on

=======End of batch=======

And to build unit-test
=======batch start=======
CD build\test\unit
nmake /f msvc.mak clean install
CD ..\..\..\

CALL bin\stl_unit_test.exe
PAUSE
CALL bin\stl_unit_testd.exe
PAUSE
CALL bin\stl_unit_testd_static.exe
PAUSE
CALL bin\stl_unit_teststld.exe
PAUSE
CALL bin\stl_unit_teststld_static.exe
PAUSE
CALL bin\stl_unit_test_static.exe
PAUSE
=======end of batch=======


Thanks to all authors of Stlport :)


----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-03-02 11:16

Message:
Logged In: YES 
user_id=1096600
Originator: NO

The localization unit tests highly depends on your platform settings.
Haven't you touch to your english locale money symbol setting for instance
the euro (€) sign for english people :-) Expected values are hard coded
in test so if you done so it might explain failure.

Have you check that boost support has any impact on this failure ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1670439&group_id=146814

[stlport-bugs] [ stlport-Bugs-1634886 ] wrong russian currency name in unittests

[SourceForge.net <noreply@so...>]

Bugs item #1634886, was opened at 2007-01-13 22:17
Message generated for change (Comment added) made by tizianomueller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1634886&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
>Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Tiziano Müller (tizianomueller)
Assigned to: Petr Ovtchenkov (complement)
Summary: wrong russian currency name in unittests

Initial Comment:
In test/unit/locale_test.cpp is "RUR" written as the russian currency name. This should be "RUB" according to my glibc and http://en.wikipedia.org/wiki/ISO_4217#Active_codes_.28sorted_by_code.29


----------------------------------------------------------------------

>Comment By: Tiziano Müller (tizianomueller)
Date: 2007-04-01 13:05

Message:
Logged In: YES 
user_id=935305
Originator: YES

Great, this shows up in 5.1.2 again. I put cout's in the code to print
them.
[...]
LocaleTest::money_put_get
        fr_FR  str_res.substr(index, p): EUR
  rl.money_int_prefix: EUR
  p_old: 4
  str_res.substr(index, p_old): EUR
  rl.money_int_prefix_old:FRF

        ru_RU.koi8r  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        en_GB  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        en_US  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        C
LocaleTest::money_put_X_bug
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::time_put_get
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::collate_facet
LocaleTest::ctype_facet
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::locale_init_problem
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
        combining 'ru_RU.koi8r' money facets with 'fr_FR' 
str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): EUR
  rl.money_int_prefix: EUR
  p_old: 4
  str_res.substr(index, p_old): EUR
  rl.money_int_prefix_old:FRF
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): EUR
  rl.money_int_prefix: EUR
  p_old: 4
  str_res.substr(index, p_old): EUR
  rl.money_int_prefix_old:FRF
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        combining 'en_GB' money facets with 'ru_RU.koi8r' 
str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): RUB
  rl.money_int_prefix: RUR
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:


../../../test/unit/locale_test.cpp(222) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old))); 
str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        combining 'en_US' money facets with 'en_GB'  str_res.substr(index,
p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): GBP
  rl.money_int_prefix: GBP
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:

        combining 'C' money facets with 'en_US'  str_res.substr(index, p):
USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
  str_res.substr(index, p): USD
  rl.money_int_prefix: USD
  p_old: 0
  str_res.substr(index, p_old):
  rl.money_int_prefix_old:
[...]

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-16 08:21

Message:
Logged In: YES 
user_id=615813
Originator: NO

My inadvertence, tests fine. Francois' fix good. Resolved.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-16 02:44

Message:
Logged In: YES 
user_id=615813
Originator: NO

BTW, see the second table in initial ref.

Seeing on this I found problem with unit tests---investigating.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-16 00:49

Message:
Logged In: YES 
user_id=615813
Originator: NO

Not all so good. glibc 2.3.6 and before has RUR here, while glibc 2.5
already has correct RUB. Something between this.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-15 21:45

Message:
Logged In: YES 
user_id=1096600
Originator: NO

Fixed in SVN trunk, thanks for the report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1634886&group_id=146814

[stlport-bugs] [ stlport-Bugs-1670439 ] some locale tests fail in 5.1.1/2 under MSVC8 with Boost

[SourceForge.net <noreply@so...>]

Bugs item #1670439, was opened at 2007-02-28 01:48
Message generated for change (Comment added) made by tizianomueller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1670439&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Tartakovsky (tartak)
Assigned to: Francois Dumont (dums)
Summary: some locale tests fail in 5.1.1/2 under MSVC8 with Boost

Initial Comment:
8 tests failed (out of 383). All 8 are in LocaleTest.
Build under VStudio 2005 (SP1) with Boost 1.33.1
Output:
===============
LocaleTest::locale_by_name
LocaleTest::loc_has_facet
LocaleTest::num_put_get
	fr_FR
	en_GB
	en_US
	C
LocaleTest::money_put_get
	fr_FR
	en_GB

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	en_US
	C
LocaleTest::money_put_X_bug
	fr_FR
	en_GB

../../../test/unit\locale_test.cpp(419) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	en_US
	C
LocaleTest::time_put_get
	fr_FR
	en_GB
	en_US
	C
LocaleTest::collate_facet
LocaleTest::ctype_facet
	fr_FR
	en_GB
	en_US
	C
LocaleTest::locale_init_problem
	fr_FR
	en_GB
	en_US
	C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
	combining 'en_GB' money facets with 'fr_FR'

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	combining 'en_US' money facets with 'en_GB'

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	combining 'C' money facets with 'en_US'

----------------------------------------------------------------------

Comment By: Tiziano Müller (tizianomueller)
Date: 2007-04-01 13:03

Message:
Logged In: YES 
user_id=935305
Originator: NO

I'm wrong, sorry. It's not the same bug.

----------------------------------------------------------------------

Comment By: Tiziano Müller (tizianomueller)
Date: 2007-04-01 12:34

Message:
Logged In: YES 
user_id=935305
Originator: NO

It's not MSVC or Windows related. I get the same errors on Linux
(glibc-2.5, x86 or ppc) with gcc-4.1.2:

LocaleTest::num_put_get
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::money_put_get
        fr_FR
        ru_RU.koi8r

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        en_GB
        en_US
        C
LocaleTest::money_put_X_bug
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::time_put_get
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::collate_facet
LocaleTest::ctype_facet
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::locale_init_problem
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
        combining 'ru_RU.koi8r' money facets with 'fr_FR'

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        combining 'en_GB' money facets with 'ru_RU.koi8r'

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        combining 'en_US' money facets with 'en_GB'
        combining 'C' money facets with 'en_US'


----------------------------------------------------------------------

Comment By: archimed7592 (archimed7592)
Date: 2007-03-20 09:06

Message:
Logged In: YES 
user_id=1747018
Originator: NO

> Here is what I do, so you can reproduce it.

I had reproduced it (mingw without boost). no effect. my 8/12 errors
kept.


I have another question: in which cases it will affect my programs (sample
code, please). I doubt, I will never use this features.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-03-09 20:38

Message:
Logged In: YES 
user_id=615813
Originator: NO

> Here is what I do, so you can reproduce it

Well, I can't: I have no Wins.

CP866, CP437, etc. --- is a DOS hangover. Looks like CP437 has pound sign,
you can check. But, of cause, it absent in CP866. So, I treat, that this OE
can't provide appropriate locale support.

> I think the test should check the
code page or, at least, warn the user to switch to the proper code page -
the one needed for the test to succeed

No. This test shouldn't do this. The test fail is signal that you have OE
with restricted support of locale, without respect how you achieve it. Not
more. Use this knowledge your own discretion. 

----------------------------------------------------------------------

Comment By: Alex Tartakovsky (tartak)
Date: 2007-03-09 20:00

Message:
Logged In: YES 
user_id=1331880
Originator: YES

Petr, what you describe is not what I do.  I use locale settings expressly
supported by OS, and documented by MS as such.  

Here is what I do, so you can reproduce it. I don't actually change the
codepage directly. I set up my locale settings (which indirectly changes
the codepage) in Control Panel/Regional and Language Options. I go to
Advanced tab there and select the "Language for non-Unicode Programs". I
change it from the default English(US) to Russian. This should not affect
Unicode programs. I need it simply because I have a few non-Unicode
programs where I want to be able to type in some text in Russian - they
would not show the text otherwise. By the way, on the same tab there is a
list of code page conversion tables installed on my computer: the ones you
mentioned, 1250-1252 are installed among many others, and I don't make any
changes there.

Now, when I change the language as described above, and then issue "chcp"
(without a parameter) command in console, I get 866. If I switch the
language back (using the same procedure) to English(US), chcp in console
gives me 437. 

According to MS Windows documentation of chcp, it shows the active console
code page. That code page is obviously what's the tests are run under.  The
documentation lists the supported code pages, here is the complete list
copied from there:

Code page Country/region or language 
437 United States 
850 Multilingual (Latin I) 
852 Slavic (Latin II) 
855 Cyrillic (Russian) 
857 Turkish 
860 Portuguese 
861 Icelandic 
863 Canadian-French 
865 Nordic 
866 Russian 
869 Modern Greek 

As you see, there is nothing outdated about 437 or 866. 437 is the
default, and 866 is supported.  All those 125x code pages are not on the
list for console.

It may very well be that there is absolutely nothing wrong with STLport,
and the problem is with the test itself. From the above, it appears clear
that, on a standard US Win XP installation, the console tests are run under
code page 437.  But the code page may be switched (even without user's
knowledge) to one of the listed above. I think the test should check the
code page or, at least, warn the user to switch to the proper code page -
the one needed for the test to succeed.

Regards, 
Lesha

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-03-09 13:27

Message:
Logged In: YES 
user_id=615813
Originator: NO

In POSIX world locale assume both locale settings and charset. You can see
explicit specification of charset: "ru_RU.koi8r". Every locale has
'default' charset, that used when charset not mentioned explicitly. en_GB
assume ISO-8859-1. The pound sterling has code 0xa3 in ISO-8859-1, so we
hardcoded this value and don't worry.

But you use old (DOS) codepages (hehe, under system with native UTF16):
866 and 437 (hmmm, why not CP1251 and CP1250/CP1252?). Or why not give
chance to wins track all encodings via native UTF16?

Really, looks like you made such OE settings that lead to poor locales
support. And tests inform you about this indeed. STLport locales based on
system support for locale, so if system don't support [may be some]
locales, we haven't chances to do work correctly.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-03-09 10:54

Message:
Logged In: YES 
user_id=1096600
Originator: NO

No it is not something expected, it would be great to make this tests more
portable. I will try to play with my system settings to see if I can break
the tests like that and then I will see if forcing code page in
localization string can safe our life.

Bests


----------------------------------------------------------------------

Comment By: Alex Tartakovsky (tartak)
Date: 2007-03-06 20:32

Message:
Logged In: YES 
user_id=1331880
Originator: YES

I tested on Win XP, US version.  But the code page was switched to 866 -
Russian.  It's under 866 that I had those errors in LocalTest.  When I
switch back to the default 437 (US), all tests succeed.  Is it something to
be expected? I mean, the tests do not warn that they must be run under a
specific code page...

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-03-04 20:56

Message:
Logged In: YES 
user_id=1096600
Originator: NO

I think the fact that you are in chinese explain why tests are not working
as expected. Could you try to specify code page in locale name and tell us
if you still have problem. You can do so replacing "fr_FR" with
"fr_FR.1252", idem for "en_EN" and "en_US".

There is a problem in your script, all builds are done configured with
msvc71 (configure -c msvc71). For VC6 and VC8 it should be different,
'configure -c msvc6' and 'configure -c msvc8' respectively.

As you are a chinese user I would like to take the opportunity of asking
you if you are happy with STLport and especially with its localization
support under Windows and Linux. Is it working fine with your language ?
Thanks for help.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-03 15:39

Message:
Logged In: NO 

some UnitTest also failed in STLport SVN(2945) under MSVC71(.Net 2003)
with SP1(KB918007) on Window XP sp2 (Traditional Chinese Version),
and Microsoft (R) Program Maintenance Utility Version 7.10.3077

Output:
=======================
LocaleTest::num_put_get
        fr_FR
        en_GB
        en_US
        C
LocaleTest::money_put_get
        fr_FR

../../../test/unit\locale_test.cpp(243) : CPPUNIT_ASSERT(str_res[index++]
== *rl.money_thousands_sep);
        en_GB

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        en_US
        C
LocaleTest::money_put_X_bug
        fr_FR
        en_GB

../../../test/unit\locale_test.cpp(419) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        en_US
        C
LocaleTest::time_put_get
        fr_FR
        en_GB
        en_US
        C
LocaleTest::collate_facet
LocaleTest::ctype_facet
        fr_FR
        en_GB
        en_US
        C
LocaleTest::locale_init_problem
        fr_FR
        en_GB
        en_US
        C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
        combining 'en_GB' money facets with 'fr_FR'

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(243) : CPPUNIT_ASSERT(str_res[index++]
== *rl.money_thousands_sep);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(243) : CPPUNIT_ASSERT(str_res[index++]
== *rl.money_thousands_sep);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        combining 'en_US' money facets with 'en_GB'

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        combining 'C' money facets with 'en_US'

========================
My build using almost the same batch scripts as followings except some
echo strings and comments are in big5 encoding. The batch scripts was
placed under the directory the same as INSTALL, doc, etc, and lib (i.e. the
root of Stlport package).


=======batch_start=======
@ECHO OFF
:: Was nmake available?
nmake /?
IF %ERRORLEVEL% EQU 0 GOTO START_COMPILE

IF EXIST "%VS80COMNTOOLS%vsvars32.bat" GOTO VC80
IF EXIST "%VS71COMNTOOLS%vsvars32.bat" GOTO VC71
IF EXIST "C:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.bat"
GOTO VC6

:VC6
CALL "C:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.bat"
GOTO START_COMPILE

:VC71
CALL "%VS71COMNTOOLS%vsvars32.bat"
GOTO START_COMPILE

:VC80
CALL "%VS80COMNTOOLS%vsvars32.bat"
GOTO START_COMPILE

:START_COMPILE
CD build\lib
CALL configure.bat --clean
CALL configure.bat -c msvc71 --extra-cxxflag /G7
nmake /f msvc.mak clean all install
cd ..\..\
GOTO END

:ERROR_MSG
ECHO Could not find vcvars32.bat!
GOTO END

:END
@ECHO on

=======End of batch=======

And to build unit-test
=======batch start=======
CD build\test\unit
nmake /f msvc.mak clean install
CD ..\..\..\

CALL bin\stl_unit_test.exe
PAUSE
CALL bin\stl_unit_testd.exe
PAUSE
CALL bin\stl_unit_testd_static.exe
PAUSE
CALL bin\stl_unit_teststld.exe
PAUSE
CALL bin\stl_unit_teststld_static.exe
PAUSE
CALL bin\stl_unit_test_static.exe
PAUSE
=======end of batch=======


Thanks to all authors of Stlport :)


----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-03-02 09:16

Message:
Logged In: YES 
user_id=1096600
Originator: NO

The localization unit tests highly depends on your platform settings.
Haven't you touch to your english locale money symbol setting for instance
the euro (€) sign for english people :-) Expected values are hard coded
in test so if you done so it might explain failure.

Have you check that boost support has any impact on this failure ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1670439&group_id=146814

[stlport-bugs] [ stlport-Bugs-1670439 ] some locale tests fail in 5.1.1/2 under MSVC8 with Boost

[SourceForge.net <noreply@so...>]

Bugs item #1670439, was opened at 2007-02-28 01:48
Message generated for change (Comment added) made by tizianomueller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1670439&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Tartakovsky (tartak)
Assigned to: Francois Dumont (dums)
Summary: some locale tests fail in 5.1.1/2 under MSVC8 with Boost

Initial Comment:
8 tests failed (out of 383). All 8 are in LocaleTest.
Build under VStudio 2005 (SP1) with Boost 1.33.1
Output:
===============
LocaleTest::locale_by_name
LocaleTest::loc_has_facet
LocaleTest::num_put_get
	fr_FR
	en_GB
	en_US
	C
LocaleTest::money_put_get
	fr_FR
	en_GB

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	en_US
	C
LocaleTest::money_put_X_bug
	fr_FR
	en_GB

../../../test/unit\locale_test.cpp(419) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	en_US
	C
LocaleTest::time_put_get
	fr_FR
	en_GB
	en_US
	C
LocaleTest::collate_facet
LocaleTest::ctype_facet
	fr_FR
	en_GB
	en_US
	C
LocaleTest::locale_init_problem
	fr_FR
	en_GB
	en_US
	C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
	combining 'en_GB' money facets with 'fr_FR'

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	combining 'en_US' money facets with 'en_GB'

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) : CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
	combining 'C' money facets with 'en_US'

----------------------------------------------------------------------

Comment By: Tiziano Müller (tizianomueller)
Date: 2007-04-01 12:34

Message:
Logged In: YES 
user_id=935305
Originator: NO

It's not MSVC or Windows related. I get the same errors on Linux
(glibc-2.5, x86 or ppc) with gcc-4.1.2:

LocaleTest::num_put_get
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::money_put_get
        fr_FR
        ru_RU.koi8r

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        en_GB
        en_US
        C
LocaleTest::money_put_X_bug
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::time_put_get
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::collate_facet
LocaleTest::ctype_facet
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::locale_init_problem
        fr_FR
        ru_RU.koi8r
        en_GB
        en_US
        C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
        combining 'ru_RU.koi8r' money facets with 'fr_FR'

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        combining 'en_GB' money facets with 'ru_RU.koi8r'

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));

../../../test/unit/locale_test.cpp(217) :
CPPUNIT_ASSERT((str_res.substr(index, p) == rl.money_int_prefix) || ((p_old
!= 0) && (str_res.substr(index, p_old) == rl.money_int_prefix_old)));
        combining 'en_US' money facets with 'en_GB'
        combining 'C' money facets with 'en_US'


----------------------------------------------------------------------

Comment By: archimed7592 (archimed7592)
Date: 2007-03-20 09:06

Message:
Logged In: YES 
user_id=1747018
Originator: NO

> Here is what I do, so you can reproduce it.

I had reproduced it (mingw without boost). no effect. my 8/12 errors
kept.


I have another question: in which cases it will affect my programs (sample
code, please). I doubt, I will never use this features.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-03-09 20:38

Message:
Logged In: YES 
user_id=615813
Originator: NO

> Here is what I do, so you can reproduce it

Well, I can't: I have no Wins.

CP866, CP437, etc. --- is a DOS hangover. Looks like CP437 has pound sign,
you can check. But, of cause, it absent in CP866. So, I treat, that this OE
can't provide appropriate locale support.

> I think the test should check the
code page or, at least, warn the user to switch to the proper code page -
the one needed for the test to succeed

No. This test shouldn't do this. The test fail is signal that you have OE
with restricted support of locale, without respect how you achieve it. Not
more. Use this knowledge your own discretion. 

----------------------------------------------------------------------

Comment By: Alex Tartakovsky (tartak)
Date: 2007-03-09 20:00

Message:
Logged In: YES 
user_id=1331880
Originator: YES

Petr, what you describe is not what I do.  I use locale settings expressly
supported by OS, and documented by MS as such.  

Here is what I do, so you can reproduce it. I don't actually change the
codepage directly. I set up my locale settings (which indirectly changes
the codepage) in Control Panel/Regional and Language Options. I go to
Advanced tab there and select the "Language for non-Unicode Programs". I
change it from the default English(US) to Russian. This should not affect
Unicode programs. I need it simply because I have a few non-Unicode
programs where I want to be able to type in some text in Russian - they
would not show the text otherwise. By the way, on the same tab there is a
list of code page conversion tables installed on my computer: the ones you
mentioned, 1250-1252 are installed among many others, and I don't make any
changes there.

Now, when I change the language as described above, and then issue "chcp"
(without a parameter) command in console, I get 866. If I switch the
language back (using the same procedure) to English(US), chcp in console
gives me 437. 

According to MS Windows documentation of chcp, it shows the active console
code page. That code page is obviously what's the tests are run under.  The
documentation lists the supported code pages, here is the complete list
copied from there:

Code page Country/region or language 
437 United States 
850 Multilingual (Latin I) 
852 Slavic (Latin II) 
855 Cyrillic (Russian) 
857 Turkish 
860 Portuguese 
861 Icelandic 
863 Canadian-French 
865 Nordic 
866 Russian 
869 Modern Greek 

As you see, there is nothing outdated about 437 or 866. 437 is the
default, and 866 is supported.  All those 125x code pages are not on the
list for console.

It may very well be that there is absolutely nothing wrong with STLport,
and the problem is with the test itself. From the above, it appears clear
that, on a standard US Win XP installation, the console tests are run under
code page 437.  But the code page may be switched (even without user's
knowledge) to one of the listed above. I think the test should check the
code page or, at least, warn the user to switch to the proper code page -
the one needed for the test to succeed.

Regards, 
Lesha

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-03-09 13:27

Message:
Logged In: YES 
user_id=615813
Originator: NO

In POSIX world locale assume both locale settings and charset. You can see
explicit specification of charset: "ru_RU.koi8r". Every locale has
'default' charset, that used when charset not mentioned explicitly. en_GB
assume ISO-8859-1. The pound sterling has code 0xa3 in ISO-8859-1, so we
hardcoded this value and don't worry.

But you use old (DOS) codepages (hehe, under system with native UTF16):
866 and 437 (hmmm, why not CP1251 and CP1250/CP1252?). Or why not give
chance to wins track all encodings via native UTF16?

Really, looks like you made such OE settings that lead to poor locales
support. And tests inform you about this indeed. STLport locales based on
system support for locale, so if system don't support [may be some]
locales, we haven't chances to do work correctly.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-03-09 10:54

Message:
Logged In: YES 
user_id=1096600
Originator: NO

No it is not something expected, it would be great to make this tests more
portable. I will try to play with my system settings to see if I can break
the tests like that and then I will see if forcing code page in
localization string can safe our life.

Bests


----------------------------------------------------------------------

Comment By: Alex Tartakovsky (tartak)
Date: 2007-03-06 20:32

Message:
Logged In: YES 
user_id=1331880
Originator: YES

I tested on Win XP, US version.  But the code page was switched to 866 -
Russian.  It's under 866 that I had those errors in LocalTest.  When I
switch back to the default 437 (US), all tests succeed.  Is it something to
be expected? I mean, the tests do not warn that they must be run under a
specific code page...

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-03-04 20:56

Message:
Logged In: YES 
user_id=1096600
Originator: NO

I think the fact that you are in chinese explain why tests are not working
as expected. Could you try to specify code page in locale name and tell us
if you still have problem. You can do so replacing "fr_FR" with
"fr_FR.1252", idem for "en_EN" and "en_US".

There is a problem in your script, all builds are done configured with
msvc71 (configure -c msvc71). For VC6 and VC8 it should be different,
'configure -c msvc6' and 'configure -c msvc8' respectively.

As you are a chinese user I would like to take the opportunity of asking
you if you are happy with STLport and especially with its localization
support under Windows and Linux. Is it working fine with your language ?
Thanks for help.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-03 15:39

Message:
Logged In: NO 

some UnitTest also failed in STLport SVN(2945) under MSVC71(.Net 2003)
with SP1(KB918007) on Window XP sp2 (Traditional Chinese Version),
and Microsoft (R) Program Maintenance Utility Version 7.10.3077

Output:
=======================
LocaleTest::num_put_get
        fr_FR
        en_GB
        en_US
        C
LocaleTest::money_put_get
        fr_FR

../../../test/unit\locale_test.cpp(243) : CPPUNIT_ASSERT(str_res[index++]
== *rl.money_thousands_sep);
        en_GB

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        en_US
        C
LocaleTest::money_put_X_bug
        fr_FR
        en_GB

../../../test/unit\locale_test.cpp(419) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        en_US
        C
LocaleTest::time_put_get
        fr_FR
        en_GB
        en_US
        C
LocaleTest::collate_facet
LocaleTest::ctype_facet
        fr_FR
        en_GB
        en_US
        C
LocaleTest::locale_init_problem
        fr_FR
        en_GB
        en_US
        C
LocaleTest::default_locale
LocaleTest::facet_id
LocaleTest::combine
        combining 'en_GB' money facets with 'fr_FR'

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(243) : CPPUNIT_ASSERT(str_res[index++]
== *rl.money_thousands_sep);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(243) : CPPUNIT_ASSERT(str_res[index++]
== *rl.money_thousands_sep);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        combining 'en_US' money facets with 'en_GB'

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);

../../../test/unit\locale_test.cpp(316) :
CPPUNIT_ASSERT(str_res.substr(index, p) == rl.money_prefix);
        combining 'C' money facets with 'en_US'

========================
My build using almost the same batch scripts as followings except some
echo strings and comments are in big5 encoding. The batch scripts was
placed under the directory the same as INSTALL, doc, etc, and lib (i.e. the
root of Stlport package).


=======batch_start=======
@ECHO OFF
:: Was nmake available?
nmake /?
IF %ERRORLEVEL% EQU 0 GOTO START_COMPILE

IF EXIST "%VS80COMNTOOLS%vsvars32.bat" GOTO VC80
IF EXIST "%VS71COMNTOOLS%vsvars32.bat" GOTO VC71
IF EXIST "C:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.bat"
GOTO VC6

:VC6
CALL "C:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.bat"
GOTO START_COMPILE

:VC71
CALL "%VS71COMNTOOLS%vsvars32.bat"
GOTO START_COMPILE

:VC80
CALL "%VS80COMNTOOLS%vsvars32.bat"
GOTO START_COMPILE

:START_COMPILE
CD build\lib
CALL configure.bat --clean
CALL configure.bat -c msvc71 --extra-cxxflag /G7
nmake /f msvc.mak clean all install
cd ..\..\
GOTO END

:ERROR_MSG
ECHO Could not find vcvars32.bat!
GOTO END

:END
@ECHO on

=======End of batch=======

And to build unit-test
=======batch start=======
CD build\test\unit
nmake /f msvc.mak clean install
CD ..\..\..\

CALL bin\stl_unit_test.exe
PAUSE
CALL bin\stl_unit_testd.exe
PAUSE
CALL bin\stl_unit_testd_static.exe
PAUSE
CALL bin\stl_unit_teststld.exe
PAUSE
CALL bin\stl_unit_teststld_static.exe
PAUSE
CALL bin\stl_unit_test_static.exe
PAUSE
=======end of batch=======


Thanks to all authors of Stlport :)


----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-03-02 09:16

Message:
Logged In: YES 
user_id=1096600
Originator: NO

The localization unit tests highly depends on your platform settings.
Haven't you touch to your english locale money symbol setting for instance
the euro (€) sign for english people :-) Expected values are hard coded
in test so if you done so it might explain failure.

Have you check that boost support has any impact on this failure ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1670439&group_id=146814