Re: svn commit: r581872 - /incubator/stdcxx/trunk/include/sstream.cc

[Martin Sebor]

[EMAIL PROTECTED] wrote:

Author: faridz
Date: Thu Oct  4 05:16:24 2007
New Revision: 581872

URL: http://svn.apache.org/viewvc?rev=581872&view=rev
Log:
2007-10-04 Farid Zaripov <[EMAIL PROTECTED]>

* Merged the head of branches/4.2.0


This change has not been sufficiently tested on trunk.

I don't have time to check the test results or otherwise verify
that the change is okay, and won't until next week, so I'll leave
it up to others to decide whether it should be reverted or if they
feel comfortable with it despite the fact that it hasn't been fully
tested.

In the future, please allow sufficient time to test all changes on
trunk before merging them to the branch. I plan to do another merge
sometime late next week so it might be safest to wait until then.

Martin



Modified:
incubator/stdcxx/trunk/include/sstream.cc

Modified: incubator/stdcxx/trunk/include/sstream.cc
URL: 
http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/sstream.cc?rev=581872&r1=581871&r2=581872&view=diff
==
--- incubator/stdcxx/trunk/include/sstream.cc (original)
+++ incubator/stdcxx/trunk/include/sstream.cc Thu Oct  4 05:16:24 2007
@@ -185,6 +185,15 @@
 const _RWSTD_SIZE_T __bufsize =
 __n + (this->pptr () - this->pbase ());
 
+_RWSTD_PTRDIFF_T __off = -1;

+
+if (this->pbase () <= __s && this->pptr () > __s) {
+// __s is a part of the buffer
+_RWSTD_ASSERT (this->epptr () >= __s + __n);
+// save the offset from pbase()
+__off = this->pbase () - __s;
+}
+
 // preserve current pptr() since str() would seek to end
 const streamsize __cur = this->pptr () - this->pbase ();
 
@@ -196,6 +205,11 @@

 this->pbump (__cur - (this->pptr () - this->pbase ()));
 
 _RWSTD_ASSERT (__n <= this->epptr () - this->pptr ());

+
+if (0 <= __off) {
+// correct __s after the buffer reallocation
+__s = this->pbase () + __off;
+}
 }
 
 // copy the whole string

Re: svn commit: r581929 - in /incubator/stdcxx/branches/4.2.0: include/loc/_punct.cc src/file.cpp

[Martin Sebor]

[EMAIL PROTECTED] wrote:

Author: faridz
Date: Thu Oct  4 07:37:59 2007
New Revision: 581929

URL: http://svn.apache.org/viewvc?rev=581929&view=rev
Log:
2007-10-04 Farid Zaripov <[EMAIL PROTECTED]>

STDCXX-564
* _punct.cc (__rw_match_name): Cast 1UL constant to _RWSTD_SIZE_T
to avoid 64-bit MSVC warning C4334: '<<' : result of 32-bit shift
implicitly converted to 64 bits (was 64-bit shift intended?).
* file.cpp [_WIN64]: Disable 64-bit MSVC warning C4244 for
__rw_fseek(), __rw_fread(), __rw_fwrite() functions.

Modified:
incubator/stdcxx/branches/4.2.0/include/loc/_punct.cc
incubator/stdcxx/branches/4.2.0/src/file.cpp

Modified: incubator/stdcxx/branches/4.2.0/include/loc/_punct.cc
URL: 
http://svn.apache.org/viewvc/incubator/stdcxx/branches/4.2.0/include/loc/_punct.cc?rev=581929&r1=581928&r2=581929&view=diff
==
--- incubator/stdcxx/branches/4.2.0/include/loc/_punct.cc (original)
+++ incubator/stdcxx/branches/4.2.0/include/loc/_punct.cc Thu Oct  4 07:37:59 
2007
@@ -87,7 +87,10 @@
 
 typedef _STD::char_traits<_CharT> _Traits;
 
-if (__bits & 1UL << __k) {

+const _RWSTD_SIZE_T __mask =
+_RWSTD_STATIC_CAST(_RWSTD_SIZE_T, 1UL) << __k;


The cast is missing a space before the open paren.

Martin


+
+if (__bits & __mask) {
 // `name' is still in the set, see if the next char matches
 // (case insensitive comparison done if `ctp' is nonzero)
 if (   __pos < __sizes [__k]
@@ -108,7 +111,7 @@
 
 // this match is a duplicate of the last best one

 // remove this match from the set
-__bits &= ~(1UL << __k);
+__bits &= ~__mask;
 --__nmatch;
 }
 else if (   __sizes [__k] < __sizes [__inx]
@@ -137,7 +140,7 @@
 
 // clear the bit for the `name' that failed to match

 // and decrement the numeber of matches
-__bits &= ~(1UL << __k);
+__bits &= ~__mask;
 --__nmatch;
 }
 }

Modified: incubator/stdcxx/branches/4.2.0/src/file.cpp
URL: 
http://svn.apache.org/viewvc/incubator/stdcxx/branches/4.2.0/src/file.cpp?rev=581929&r1=581928&r2=581929&view=diff
==
--- incubator/stdcxx/branches/4.2.0/src/file.cpp (original)
+++ incubator/stdcxx/branches/4.2.0/src/file.cpp Thu Oct  4 07:37:59 2007
@@ -475,13 +475,18 @@
 }
 
 
+#ifdef _WIN64

+// disable MSVC warning: conversion from '__int64' to 'long', possible loss of 
data
+#pragma warning (disable: 4244)
+#endif


I'm not sure we want to simply silence the warning here. It points out
a real problem in our library on Windows, i.e., that __rw_fseek() cannot
seek past the range of 32-bits. We should open an issue for this to
remember to revisit this limitation in the future (and then it will
be appropriate to silence the warning :)

Martin


+
 _RWSTD_EXPORT long
 __rw_fseek (void *file, int flags, _RWSTD_PTRDIFF_T offset, int origin)
 {
 if (flags & _RWSTD_IOS_STDIO) {
 FILE* const fp = _RWSTD_STATIC_CAST (FILE*, file);
 
-const int pos = fseek (fp, offset, origin);

+const int pos = fseek (fp, long (offset), origin);
 if (pos < 0)
 return long (pos);
 
@@ -522,6 +527,11 @@
 
 return write (fd, buf, size);

 }
+
+#ifdef _WIN64
+// restore MSVC warning: conversion from '__int64' to 'long', possible loss of 
data
+#pragma warning (default: 4244)
+#endif
 
 
 _RWSTD_EXPORT extern const void* __rw_std_streams[];

Re: svn commit: r581935 - in /incubator/stdcxx/trunk: include/loc/_punct.cc src/file.cpp

[Martin Sebor]

[EMAIL PROTECTED] wrote:

Author: faridz
Date: Thu Oct  4 07:45:07 2007
New Revision: 581935

URL: http://svn.apache.org/viewvc?rev=581935&view=rev


Has this change been sufficiently tested on trunk before being
merging out to the branch?

Martin


Log:
2007-10-04 Farid Zaripov <[EMAIL PROTECTED]>

* Merged the head of branches/4.2.0

Modified:
incubator/stdcxx/trunk/include/loc/_punct.cc
incubator/stdcxx/trunk/src/file.cpp

Modified: incubator/stdcxx/trunk/include/loc/_punct.cc
URL: 
http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/loc/_punct.cc?rev=581935&r1=581934&r2=581935&view=diff
==
--- incubator/stdcxx/trunk/include/loc/_punct.cc (original)
+++ incubator/stdcxx/trunk/include/loc/_punct.cc Thu Oct  4 07:45:07 2007
@@ -87,7 +87,10 @@
 
 typedef _STD::char_traits<_CharT> _Traits;
 
-if (__bits & 1UL << __k) {

+const _RWSTD_SIZE_T __mask =
+_RWSTD_STATIC_CAST(_RWSTD_SIZE_T, 1UL) << __k;
+
+if (__bits & __mask) {
 // `name' is still in the set, see if the next char matches
 // (case insensitive comparison done if `ctp' is nonzero)
 if (   __pos < __sizes [__k]
@@ -108,7 +111,7 @@
 
 // this match is a duplicate of the last best one

 // remove this match from the set
-__bits &= ~(1UL << __k);
+__bits &= ~__mask;
 --__nmatch;
 }
 else if (   __sizes [__k] < __sizes [__inx]
@@ -137,7 +140,7 @@
 
 // clear the bit for the `name' that failed to match

 // and decrement the numeber of matches
-__bits &= ~(1UL << __k);
+__bits &= ~__mask;
 --__nmatch;
 }
 }

Modified: incubator/stdcxx/trunk/src/file.cpp
URL: 
http://svn.apache.org/viewvc/incubator/stdcxx/trunk/src/file.cpp?rev=581935&r1=581934&r2=581935&view=diff
==
--- incubator/stdcxx/trunk/src/file.cpp (original)
+++ incubator/stdcxx/trunk/src/file.cpp Thu Oct  4 07:45:07 2007
@@ -475,13 +475,18 @@
 }
 
 
+#ifdef _WIN64

+// disable MSVC warning: conversion from '__int64' to 'long', possible loss of 
data
+#pragma warning (disable: 4244)
+#endif
+
 _RWSTD_EXPORT long
 __rw_fseek (void *file, int flags, _RWSTD_PTRDIFF_T offset, int origin)
 {
 if (flags & _RWSTD_IOS_STDIO) {
 FILE* const fp = _RWSTD_STATIC_CAST (FILE*, file);
 
-const int pos = fseek (fp, offset, origin);

+const int pos = fseek (fp, long (offset), origin);
 if (pos < 0)
 return long (pos);
 
@@ -522,6 +527,11 @@
 
 return write (fd, buf, size);

 }
+
+#ifdef _WIN64
+// restore MSVC warning: conversion from '__int64' to 'long', possible loss of 
data
+#pragma warning (default: 4244)
+#endif
 
 
 _RWSTD_EXPORT extern const void* __rw_std_streams[];

Re: [RFC] stdcxx acknowledgments

[Martin Sebor]

Andrew Black wrote:

Greetings all.

One thought that I have looking over the proposed patch is that it
doesn't include the names of people who have contribute code to the
release, but who aren't comitters.  Scott Zhong and Travis Vitek both
have changes attributed to them, but neither name appears in the list.
I suspect there are others, but it would require a search through the
change logs to locate the changes in question.


True. I think the question we would need to ask ourselves is: where
do we draw the line? More specifically, what are the minimum criteria
for a person to meet to be acknowledged.

If we were to decide to acknowledge everyone who ever contributed any
code (which, presumably, ended up getting committed), we could simply
search our ChangeLogs for the unique names of patch authors.

I still think the safest way to proceed is to rename the page to
history.html and keep the names that are already on it (or some
subset thereof, whatever we decide) under the section describing
the Rogue Wave ancestry of stdcxx.

Martin



--Andrew Black

Martin Sebor wrote:

In the patch attached to the issue Marc proposes to replace
the names of the original Rogue Wave "contributors" to the
project (which included support engineers as well management)
with those of stdcxx committers (including Emeriti). I'd like
to request people's opinion on this change. I personally am
not entirely comfortable dropping all the contributors that
predate stdcxx, although perhaps it may not be inappropriate
(sorry for the double negative) to pare it down to people who
contributed significant code and/or documentation changes).

What do others think?

Martin

Marc Betz (JIRA) wrote:

 [
https://issues.apache.org/jira/browse/STDCXX-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marc Betz updated STDCXX-505:
-

Attachment: (was: acknow.html)


Update the Acknowledgments page
---

Key: STDCXX-505
URL: https://issues.apache.org/jira/browse/STDCXX-505
Project: C++ Standard Library
 Issue Type: Sub-task
 Components: Documentation
   Affects Versions: 4.1.2, 4.1.3, 4.1.4
   Reporter: Marc Betz
   Assignee: Marc Betz
Fix For: 4.2

Re: Purify run results

[Martin Sebor]

Travis Vitek wrote:

I spent some time looking through these results and it looks like the HP
compiler is generating code that results in many unexpected UMR
[Uninitialized Memory Read] errors. I'm not exactly sure what to do with
the information I've gathered, so I'm posting it here. Here is my simple
testcase and other relevant information.

[EMAIL PROTECTED] ~]$ cat t.cpp

struct random_access_iterator_tag
{ 
#ifdef _TAG

random_access_iterator_tag () : _C_dummy(0) {}
char _C_dummy;
#endif
};

void distance(random_access_iterator_tag)
{
}

int main()
{
const random_access_iterator_tag __tag;
distance (__tag); // <-- umr here


The UMR is real, isn't it? I.e., __tag is not initialized but
it's being copied to the function argument. Do other compilers
eliminate the copy?

Martin



return 0;
}

[EMAIL PROTECTED] ~]$ purify -log-file=t.log -windows=no aCC-g t.cpp
2> /dev/null && ./a.out && grep "^UMR" t.log
UMR: Uninitialized memory read:
[EMAIL PROTECTED] ~]$ purify -log-file=t.log -windows=no aCC -D_TAG -g t.cpp
2> /dev/null && ./a.out && grep "^UMR" t.log
[EMAIL PROTECTED] ~]$ 


Here is the purify message...

UMR: Uninitialized memory read:
  * This is occurring while in:
main   [t.cpp:17]
_start [libc.2]
$START$[crt0.o]
$START$[crt0.o]
  * Reading 1 byte from 0x7f7f0b88 on the stack.
  * Address 0x7f7f0b88 is local variable "__tag" in function main.

Here is the disassembly for the original code. You can see that a byte
from -0x38(%sp) is loaded into %r17, but nothing was ever stored there.

0x5296c :nop
0x52970 :call,n 0x5293c <_main>
0x52974 :break 0,0
0x52978 :be,l -0xdd8(%sr3,%r18),%sr0,%r31
0x5297c :copy %sp,%r17
;;;  17 distance (__tag);
0x52980 :be,l -0xfb8(%sr3,%r18),%sr0,%r31
0x52984 :ldo -0x38(%sp),%r17 ; <-- load here, but no
previous store
0x52988 :ldb -0x38(%sp),%r26 ; <-- load here, but no
previous store
0x5298c :be,l,n -0xdfc(%sr3,%r18),%sr0,%r31
0x52990 :nop

Here is the disassembly for the case that gets no UMR message. You can
see that a byte is stored at -0x38(%sp) before it is loaded.

0x5296c :nop
0x52970 :call,n 0x5293c <_main>
0x52974 :break 0,0
0x52978 :be,l -0xdd8(%sr3,%r18),%sr0,%r31
0x5297c :copy %sp,%r17
;;;  16 const random_access_iterator_tag __tag;
0x52980 :be,l -0xef8(%sr3,%r18),%sr0,%r31
0x52984 :ldo -0x38(%sp),%r17
0x52988 :stb %r0,-0x38(%sp) ; <-- store here
;;;  17 distance (__tag);
0x5298c :be,l -0xfb8(%sr3,%r18),%sr0,%r31
0x52990 :ldo -0x38(%sp),%r17 ; <-- load here
0x52994 :ldb -0x38(%sp),%r26 ; <-- load here
0x52998 :be,l,n -0xdfc(%sr3,%r18),%sr0,%r31
0x5299c :nop

This issue causes Purify warnings in any function that passes an empty
class as a parameter to a function by value. Nearly any function that
touches the iterator tag types will give a UMR warning because of this
problem.

Travis


From: Andrew Black

Greetings all.

As I mentioned in my previous email, I've performed a test build of the
apache standard library using Rational
PurifyPlus 7.0 ( http://www.ibm.com/software/awdtools/purifyplus/ ).
This build was performed on an HPUX 11.23 machine, using the 
HP acc 3.73

compiler and subversion trunk at
r580086 plus the makefile.rules part of the purify.diff patch attached
to STDCXX-573.  PURE_OPTS was set to '[EMAIL PROTECTED]
-windows=no -append-logfile=yes [EMAIL PROTECTED]
-always-use-cache-dir=yes -cache-dir=/tmp/ablack-purecache-stdcx'.  If
anyone wishes to look at the results of this build, it can be retrieved
from http://people.apache.org/~ablack/stdcxx-4.2.0-rc-5-purify.tar.gz .
This build was a 15d build, which was processed with `make clean` and
`make dependclean` prior to being compressed.

Note that some of the .log files were truncated by Purify 
during the run

process due to their length.  These files are
22.locale.money.put.log, tests/22.locale.moneypunct.log,
tests/22.locale.num.get.log, tests/23.deque.modifiers.log,
tests/25.find.end.log, and tests/25.search.log.

--Andrew Black

Re: 22.locale.moneypunct test fails on MSVC

[Martin Sebor]

Farid Zaripov wrote:

-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Wednesday, October 03, 2007 11:21 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: 22.locale.moneypunct test fails on MSVC

Farid Zaripov wrote:
  The 22.locale.moneypunct test fails on MSVC (and 
ICC/Windows) due to 

bug of the CRT or native API.

  The following program aborts on assert (tested on all MSVC's on 
Windows XP 32 and 64 bit). This program fails only for some 
locales. 

So it fails with locname = "Catalan_Spain.1252"
but succeeds with locname = "Russian_Russia.1251".
Hmm. That makes the LC_MONETARY category pretty much unusable 
on Windows. We need to open a bug with Microsoft and get this 
fixed.


  Now I think that it's not a bug of the MSVC. My system locale is
Russian_Russia.1251 (codepage = 1251). When LC_MONETARY
id used, the unicode value of the euro sign is converted into 1251
codepage (using WideCharToMultiByte() API function). 


From etc/nls/charmaps/CP1251 (/x88 == -120):

 /x88 EURO SIGN

  And when LC_ALL is used, the unicode value of the euro sign is
converted into 1252 codepage.


From etc/nls/charmaps/CP1252 (/x80 == -128):

 /x80 EURO SIGN

  The std::moneypunct<> facet uses setlocale (LC_ALL, ) when initializes
the facet data, so I think the 22.locale.moneypunct.cpp test should use
setlocale (LC_ALL, ) instead of setlocale (LC_MONETARY, ), or use
setlocale (LC_CTYPE, ) before setlocale (LC_MONETARY, )..


You might very well be right. LC_MONETARY affects the values
of the punctuators but LC_CTYPE determines their multibyte
encoding.

Martin

[jira] Created: (STDCXX-580) purify reports memory leaked by strstream example

[Travis Vitek (JIRA)]

purify reports memory leaked by strstream example 
--

 Key: STDCXX-580
 URL: https://issues.apache.org/jira/browse/STDCXX-580
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Examples
Reporter: Travis Vitek
Assignee: Travis Vitek
Priority: Minor
 Fix For: 4.2.1
 Attachments: stdcxx-580.patch

The example calls inout.str() which calls freeze(). If the streams streambuf if 
frozen, the destructor is not allowed to free the memory [D.7.1.2 p8]. 

  Purify instrumented ./strstream (pid 21780)  
Purify: Searching for all memory leaks...

Memory leaked: 128 bytes (1.15%); potentially leaked: 0 bytes (0%)

MLK: 128 bytes leaked at 0x40027788
  * This memory was allocated from:
malloc [rtlib.o]
__nWa__FuL [libCsup_v2.2]
operator new[](unsigned long) [rtlib.o]
std::strstreambuf::setbuf(char *,long) [strstream.cpp:294]
std::strstreambuf::overflow(int) [strstream.cpp:85]
std::basic_streambuf>::xsputn(const char 
*,long) [streambuf.cc:144]


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-580) purify reports memory leaked by strstream example

[Travis Vitek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek updated STDCXX-580:


Attachment: stdcxx-580.patch

2007-10-04  Travis Vitek  <[EMAIL PROTECTED]>

STDCXX-579
* strstream.cpp (main): Unfreeze streambuf so destructor
will deallocate memory.


> purify reports memory leaked by strstream example 
> --
>
> Key: STDCXX-580
> URL: https://issues.apache.org/jira/browse/STDCXX-580
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: Examples
>Reporter: Travis Vitek
>Assignee: Travis Vitek
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-580.patch
>
>
> The example calls inout.str() which calls freeze(). If the streams streambuf 
> if frozen, the destructor is not allowed to free the memory [D.7.1.2 p8]. 
>   Purify instrumented ./strstream (pid 21780)  
> Purify: Searching for all memory leaks...
> Memory leaked: 128 bytes (1.15%); potentially leaked: 0 bytes (0%)
> MLK: 128 bytes leaked at 0x40027788
>   * This memory was allocated from:
>   malloc [rtlib.o]
>   __nWa__FuL [libCsup_v2.2]
>   operator new[](unsigned long) [rtlib.o]
>   std::strstreambuf::setbuf(char *,long) [strstream.cpp:294]
>   std::strstreambuf::overflow(int) [strstream.cpp:85]
>   std::basic_streambuf>::xsputn(const char 
> *,long) [streambuf.cc:144]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-579) purify reports memory leaked by strstreambuf example

[Travis Vitek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek updated STDCXX-579:


  Severity: Incorrect Behavior
Issue Type: Improvement  (was: Bug)

> purify reports memory leaked by strstreambuf example
> 
>
> Key: STDCXX-579
> URL: https://issues.apache.org/jira/browse/STDCXX-579
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: Examples
>Reporter: Travis Vitek
>Assignee: Travis Vitek
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-579.patch
>
>
> The example calls out.rdbuf()->str() which calls freeze(). If the buffer if 
> frozen, the destructir is not allowed to free the memory [D.7.1.2 p8].
>   Purify instrumented ./strstreambuf (pid 27069)  
> Purify: Searching for all memory leaks...
> Memory leaked: 200 bytes (100%); potentially leaked: 0 bytes (0%)
> MLK: 200 bytes leaked at 0x80c01d8
>   * This memory was allocated from:
>   malloc [rtlib.o]
>   operator new(unsigned) [libstd15d.so]
>   operator new [](unsigned) [libstd15d.so]
>   std::strstreambuf::setbuf(char*, int) [strstream.cpp:292]
>   std::basic_streambuf >::pubsetbuf(char*, 
> int) [streambuf:91]
>   main   [strstreambuf.cpp:78]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-577) purify reports leaked memory in stocks example

[Travis Vitek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek updated STDCXX-577:


Summary: purify reports leaked memory in stocks example   (was: stocks 
example purify results indicate leaked memory)

> purify reports leaked memory in stocks example 
> ---
>
> Key: STDCXX-577
> URL: https://issues.apache.org/jira/browse/STDCXX-577
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: Examples
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-577.patch, stocks.log
>
>
> It is pretty obvious from looking at the source that memory is being leaked. 
> The destructor for StockXchange doesn't deallocate memory allocated in 
> StockXchange::add(), and the sl_pairs allocated in main are never deallocated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-579) purify reports memory leaked by strstreambuf example

[Travis Vitek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek updated STDCXX-579:


Patch Info: [Patch Available]

> purify reports memory leaked by strstreambuf example
> 
>
> Key: STDCXX-579
> URL: https://issues.apache.org/jira/browse/STDCXX-579
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Examples
>Reporter: Travis Vitek
>Assignee: Travis Vitek
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-579.patch
>
>
> The example calls out.rdbuf()->str() which calls freeze(). If the buffer if 
> frozen, the destructir is not allowed to free the memory [D.7.1.2 p8].
>   Purify instrumented ./strstreambuf (pid 27069)  
> Purify: Searching for all memory leaks...
> Memory leaked: 200 bytes (100%); potentially leaked: 0 bytes (0%)
> MLK: 200 bytes leaked at 0x80c01d8
>   * This memory was allocated from:
>   malloc [rtlib.o]
>   operator new(unsigned) [libstd15d.so]
>   operator new [](unsigned) [libstd15d.so]
>   std::strstreambuf::setbuf(char*, int) [strstream.cpp:292]
>   std::basic_streambuf >::pubsetbuf(char*, 
> int) [streambuf:91]
>   main   [strstreambuf.cpp:78]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-579) purify reports memory leaked by strstreambuf example

[Travis Vitek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek updated STDCXX-579:


Attachment: stdcxx-579.patch

2007-10-04  Travis Vitek  <[EMAIL PROTECTED]>

STDCXX-579
* strstreambuf.cpp (main): Unfreeze streambuf so destructor
will deallocate memory.

> purify reports memory leaked by strstreambuf example
> 
>
> Key: STDCXX-579
> URL: https://issues.apache.org/jira/browse/STDCXX-579
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Examples
>Reporter: Travis Vitek
>Assignee: Travis Vitek
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-579.patch
>
>
> The example calls out.rdbuf()->str() which calls freeze(). If the buffer if 
> frozen, the destructir is not allowed to free the memory [D.7.1.2 p8].
>   Purify instrumented ./strstreambuf (pid 27069)  
> Purify: Searching for all memory leaks...
> Memory leaked: 200 bytes (100%); potentially leaked: 0 bytes (0%)
> MLK: 200 bytes leaked at 0x80c01d8
>   * This memory was allocated from:
>   malloc [rtlib.o]
>   operator new(unsigned) [libstd15d.so]
>   operator new [](unsigned) [libstd15d.so]
>   std::strstreambuf::setbuf(char*, int) [strstream.cpp:292]
>   std::basic_streambuf >::pubsetbuf(char*, 
> int) [streambuf:91]
>   main   [strstreambuf.cpp:78]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-579) purify reports memory leaked by strstreambuf example

[Travis Vitek (JIRA)]

purify reports memory leaked by strstreambuf example


 Key: STDCXX-579
 URL: https://issues.apache.org/jira/browse/STDCXX-579
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Examples
Reporter: Travis Vitek
Assignee: Travis Vitek
Priority: Minor
 Fix For: 4.2.1


The example calls out.rdbuf()->str() which calls freeze(). If the buffer if 
frozen, the destructir is not allowed to free the memory [D.7.1.2 p8].

  Purify instrumented ./strstreambuf (pid 27069)  
Purify: Searching for all memory leaks...

Memory leaked: 200 bytes (100%); potentially leaked: 0 bytes (0%)

MLK: 200 bytes leaked at 0x80c01d8
  * This memory was allocated from:
malloc [rtlib.o]
operator new(unsigned) [libstd15d.so]
operator new [](unsigned) [libstd15d.so]
std::strstreambuf::setbuf(char*, int) [strstream.cpp:292]
std::basic_streambuf >::pubsetbuf(char*, 
int) [streambuf:91]
main   [strstreambuf.cpp:78]


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (STDCXX-578) purify reports mismatched new/delete in facet implementation.

[Travis Vitek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek reassigned STDCXX-578:
---

Assignee: Travis Vitek

> purify reports mismatched new/delete in facet implementation.
> -
>
> Key: STDCXX-578
> URL: https://issues.apache.org/jira/browse/STDCXX-578
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-578.patch
>
>
>   Purify instrumented ./stocks (pid 19642)  
> FMM: Freeing mismatched memory:
>   * This is occurring while in thread 19642:
> operator delete(*) [rtlib.o]
> __rw::__rw_facet::~__rw_facet[not-in-charge]() [facet.cpp:139]
> std::time_put 
> > >::~time_put[not-in-charge]() [_time_put.h:105]
> std::time_put_byname std::char_traits > >::~time_put_byname[in-charge deleting]() 
> [ti_time_put.cpp:105]
> __rw::__rw_facet::_C_manage(__rw::__rw_facet*, 
> __rw::__rw_facet::_C_facet_type, char const*, __rw::__rw_facet*  
> (*)(unsigned, char const*)) [facet.cpp:427]
> __rw::__rw_locale::~__rw_locale[in-charge]() [locale_body.cpp:692]
>   * Attempting to free block at 0x80f3fe0 in the heap.
>   * Address 0x80f3fe0 is at the beginning of a malloc'd block of 2452 bytes.
>   * This block was allocated from thread -1207973632:
> malloc [rtlib.o]
> operator new(unsigned) [libstd15d.so]
> operator new [](unsigned) [libstd15d.so]
> __rw::__rw_get_timepunct(__rw::__rw_facet const*, int, unsigned) 
> [time_put.cpp:454]
> __rw::__rw_get_time_put_data(__rw::__rw_time_put_data&, __rw::__rw_facet 
> const*, tm const*, char, char, bool) [time_put.cpp:2115]
> __rw::__rw_put_time(__rw::__rw_facet const*, char*, unsigned, 
> std::ios_base&, char, tm const*, char, char, int, int) [time_put.cpp:2666]
>   * This block of memory was obtained using an allocation routine which is
> not compatible with the routine by which it is being freed.
> Memory is allocated with array new, but deallocated with operator delete.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-578) purify reports mismatched new/delete in facet implementation.

[Travis Vitek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek updated STDCXX-578:


Attachment: stdcxx-578.patch


2007-10-04  Travis Vitek  <[EMAIL PROTECTED]>

STDCXX-578
* time_put.cpp (__rw_get_timepunct): changed to use operator
new/delete for memory allocation to avoid new/delete mismatch with
facet destructor.


> purify reports mismatched new/delete in facet implementation.
> -
>
> Key: STDCXX-578
> URL: https://issues.apache.org/jira/browse/STDCXX-578
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Reporter: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-578.patch
>
>
>   Purify instrumented ./stocks (pid 19642)  
> FMM: Freeing mismatched memory:
>   * This is occurring while in thread 19642:
> operator delete(*) [rtlib.o]
> __rw::__rw_facet::~__rw_facet[not-in-charge]() [facet.cpp:139]
> std::time_put 
> > >::~time_put[not-in-charge]() [_time_put.h:105]
> std::time_put_byname std::char_traits > >::~time_put_byname[in-charge deleting]() 
> [ti_time_put.cpp:105]
> __rw::__rw_facet::_C_manage(__rw::__rw_facet*, 
> __rw::__rw_facet::_C_facet_type, char const*, __rw::__rw_facet*  
> (*)(unsigned, char const*)) [facet.cpp:427]
> __rw::__rw_locale::~__rw_locale[in-charge]() [locale_body.cpp:692]
>   * Attempting to free block at 0x80f3fe0 in the heap.
>   * Address 0x80f3fe0 is at the beginning of a malloc'd block of 2452 bytes.
>   * This block was allocated from thread -1207973632:
> malloc [rtlib.o]
> operator new(unsigned) [libstd15d.so]
> operator new [](unsigned) [libstd15d.so]
> __rw::__rw_get_timepunct(__rw::__rw_facet const*, int, unsigned) 
> [time_put.cpp:454]
> __rw::__rw_get_time_put_data(__rw::__rw_time_put_data&, __rw::__rw_facet 
> const*, tm const*, char, char, bool) [time_put.cpp:2115]
> __rw::__rw_put_time(__rw::__rw_facet const*, char*, unsigned, 
> std::ios_base&, char, tm const*, char, char, int, int) [time_put.cpp:2666]
>   * This block of memory was obtained using an allocation routine which is
> not compatible with the routine by which it is being freed.
> Memory is allocated with array new, but deallocated with operator delete.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-578) purify reports mismatched new/delete in facet implementation.

[Travis Vitek (JIRA)]

purify reports mismatched new/delete in facet implementation.
-

 Key: STDCXX-578
 URL: https://issues.apache.org/jira/browse/STDCXX-578
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Reporter: Travis Vitek
 Fix For: 4.2.1


  Purify instrumented ./stocks (pid 19642)  
FMM: Freeing mismatched memory:
  * This is occurring while in thread 19642:
operator delete(*) [rtlib.o]
__rw::__rw_facet::~__rw_facet[not-in-charge]() [facet.cpp:139]
std::time_put > 
>::~time_put[not-in-charge]() [_time_put.h:105]
std::time_put_byname > >::~time_put_byname[in-charge deleting]() 
[ti_time_put.cpp:105]
__rw::__rw_facet::_C_manage(__rw::__rw_facet*, 
__rw::__rw_facet::_C_facet_type, char const*, __rw::__rw_facet*  (*)(unsigned, 
char const*)) [facet.cpp:427]
__rw::__rw_locale::~__rw_locale[in-charge]() [locale_body.cpp:692]
  * Attempting to free block at 0x80f3fe0 in the heap.
  * Address 0x80f3fe0 is at the beginning of a malloc'd block of 2452 bytes.
  * This block was allocated from thread -1207973632:
malloc [rtlib.o]
operator new(unsigned) [libstd15d.so]
operator new [](unsigned) [libstd15d.so]
__rw::__rw_get_timepunct(__rw::__rw_facet const*, int, unsigned) 
[time_put.cpp:454]
__rw::__rw_get_time_put_data(__rw::__rw_time_put_data&, __rw::__rw_facet 
const*, tm const*, char, char, bool) [time_put.cpp:2115]
__rw::__rw_put_time(__rw::__rw_facet const*, char*, unsigned, 
std::ios_base&, char, tm const*, char, char, int, int) [time_put.cpp:2666]
  * This block of memory was obtained using an allocation routine which is
not compatible with the routine by which it is being freed.

Memory is allocated with array new, but deallocated with operator delete.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-577) stocks example purify results indicate leaked memory

[Travis Vitek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek updated STDCXX-577:


Attachment: stdcxx-577.patch
stocks.log

Attaching purify log and patch.

2007-10-04  Travis Vitek  <[EMAIL PROTECTED]>

STDCXX-577
* stocks.h: Removed StockXchange destructor implementation.
* stocks.cpp: Changed StockXchange destructor to deallocate memory.
(main): Deallocate memory.

> stocks example purify results indicate leaked memory
> 
>
> Key: STDCXX-577
> URL: https://issues.apache.org/jira/browse/STDCXX-577
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: Examples
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-577.patch, stocks.log
>
>
> It is pretty obvious from looking at the source that memory is being leaked. 
> The destructor for StockXchange doesn't deallocate memory allocated in 
> StockXchange::add(), and the sl_pairs allocated in main are never deallocated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-577) stocks example purify results indicate leaked memory

[Travis Vitek (JIRA)]

stocks example purify results indicate leaked memory


 Key: STDCXX-577
 URL: https://issues.apache.org/jira/browse/STDCXX-577
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Examples
Reporter: Travis Vitek
 Fix For: 4.2.1


It is pretty obvious from looking at the source that memory is being leaked. 
The destructor for StockXchange doesn't deallocate memory allocated in 
StockXchange::add(), and the sl_pairs allocated in main are never deallocated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (STDCXX-577) stocks example purify results indicate leaked memory

[Travis Vitek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Travis Vitek reassigned STDCXX-577:
---

Assignee: Travis Vitek

> stocks example purify results indicate leaked memory
> 
>
> Key: STDCXX-577
> URL: https://issues.apache.org/jira/browse/STDCXX-577
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: Examples
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
>
> It is pretty obvious from looking at the source that memory is being leaked. 
> The destructor for StockXchange doesn't deallocate memory allocated in 
> StockXchange::add(), and the sl_pairs allocated in main are never deallocated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-505) Update the Acknowledgments page

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532520
 ] 

Eric Lemings commented on STDCXX-505:
-

The AUTHORS file is dictated by the --gnu option in GNU Automake.

http://sources.redhat.com/automake/automake.html#Gnits

GNU Automake extends the GNU Coding Standards with release, distribution, and 
maintenance conventions.


> Update the Acknowledgments page
> ---
>
> Key: STDCXX-505
> URL: https://issues.apache.org/jira/browse/STDCXX-505
> Project: C++ Standard Library
>  Issue Type: Sub-task
>  Components: Documentation
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
>Reporter: Marc Betz
>Assignee: Marc Betz
> Fix For: 4.2
>
> Attachments: stdlibref-acknow.txt, stdlibug-acknow.txt
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[PATCH] 22.locale.ctype.narrow.cpp

[Farid Zaripov]

  ChangeLog:
  * 22.locale.ctype.narrow.cpp: Move libc_mask (, wchar_t, )
  and libc_is (, wchar_t, ) functions up before the first use
  in cond1 (, char, ).
  Remove #ifndef _RWSTD_NO_WCHAR_T / #endif preprocessor
  directives as unusual.
  (narrow): Check the return value of the wctob().


Index: tests/localization/22.locale.ctype.narrow.cpp
===
--- tests/localization/22.locale.ctype.narrow.cpp   (revision
581916)
+++ tests/localization/22.locale.ctype.narrow.cpp   (working copy)
@@ -165,6 +165,53 @@
 return 0 != (m & mask);
 }
 
+std::ctype_base::mask libc_mask (int mask, wchar_t ch, const char
*locname)
+{
+char curlocname [256];
+
+if (locname) {
+std::strcpy (curlocname, std::setlocale (LC_CTYPE, 0));
+
+if (0 == std::setlocale (LC_CTYPE, locname))
+return std::ctype_base::mask ();
+}
+
+int result = 0;
+
+if (mask & ALPHA && (std::iswalpha)(ch))
+result |= ALPHA;
+if (mask & CNTRL && (std::iswcntrl)(ch))
+result |= CNTRL;
+if (mask & DIGIT && (std::iswdigit)(ch))
+result |= DIGIT;
+if (mask & GRAPH && (std::iswgraph)(ch))
+result |= GRAPH;
+if (mask & LOWER && (std::iswlower)(ch))
+result |= LOWER;
+if (mask & PRINT && (std::iswprint)(ch))
+result |= PRINT;
+if (mask & PUNCT && (std::iswpunct)(ch))
+result |= PUNCT;
+if (mask & SPACE && (std::iswspace)(ch))
+result |= SPACE;
+if (mask & UPPER && (std::iswupper)(ch))
+result |= UPPER;
+if (mask & XDIGIT && (std::iswxdigit)(ch))
+result |= XDIGIT;
+
+if (locname)
+std::setlocale (LC_CTYPE, curlocname);
+
+return std::ctype_base::mask (result);
+}
+
+bool libc_is (std::ctype_base::mask mask, wchar_t ch, const char
*locname)
+{
+const std::ctype_base::mask m = libc_mask (mask, ch, locname);
+
+return 0 != (m & mask);
+}
+
 const char* narrow (char *dst, const char *src)
 {
 if (src == dst || !src || !dst)
@@ -244,8 +291,6 @@
 }
 
 
-#ifndef _RWSTD_NO_WCHAR_T
-
 const char* narrow (char *dst, const wchar_t *src)
 {
 static char buf [4096];
@@ -291,53 +336,6 @@
 return dst;
 }
 
-std::ctype_base::mask libc_mask (int mask, wchar_t ch, const char
*locname)
-{
-char curlocname [256];
-
-if (locname) {
-std::strcpy (curlocname, std::setlocale (LC_CTYPE, 0));
-
-if (0 == std::setlocale (LC_CTYPE, locname))
-return std::ctype_base::mask ();
-}
-
-int result = 0;
-
-if (mask & ALPHA && (std::iswalpha)(ch))
-result |= ALPHA;
-if (mask & CNTRL && (std::iswcntrl)(ch))
-result |= CNTRL;
-if (mask & DIGIT && (std::iswdigit)(ch))
-result |= DIGIT;
-if (mask & GRAPH && (std::iswgraph)(ch))
-result |= GRAPH;
-if (mask & LOWER && (std::iswlower)(ch))
-result |= LOWER;
-if (mask & PRINT && (std::iswprint)(ch))
-result |= PRINT;
-if (mask & PUNCT && (std::iswpunct)(ch))
-result |= PUNCT;
-if (mask & SPACE && (std::iswspace)(ch))
-result |= SPACE;
-if (mask & UPPER && (std::iswupper)(ch))
-result |= UPPER;
-if (mask & XDIGIT && (std::iswxdigit)(ch))
-result |= XDIGIT;
-
-if (locname)
-std::setlocale (LC_CTYPE, curlocname);
-
-return std::ctype_base::mask (result);
-}
-
-bool libc_is (std::ctype_base::mask mask, wchar_t ch, const char
*locname)
-{
-const std::ctype_base::mask m = libc_mask (mask, ch, locname);
-
-return 0 != (m & mask);
-}
-
 wchar_t widen (wchar_t, char ch, const char *locname)
 {
 char curlocname [256];
@@ -381,7 +379,8 @@
 
 #ifndef _RWSTD_NO_WCTOB
 
-result [0] = std::wctob (ch);
+const int tmp = std::wctob (ch);
+result [0] = EOF == tmp ? '\377' : char (tmp);
 
 #elif !defined (_RWSTD_NO_WCTOMB)
 
@@ -431,8 +430,6 @@
 return result;
 }
 
-#endif   // _RWSTD_NO_WCHAR_T
-
 
/***
***/
 
 template 


Farid.

[PATCH] ctype fixes

[Farid Zaripov]

  The following patch fixes the rw_asserts in 22.locale.ctype.narrow.cpp
test.

  ChangeLog:
  * _ctype.h (ctype::narrow): Don't cast __c to unsigned char
  to avoid using the same __idx for the different __c (i.e. 2 and 258).
  * wctype.cpp (ctype_byname::do_narrow): Compare tmp with
  _RWSTD_EOF instead of < 0. Set locale before invoking wctomb().
  (ctype_byname::do_widen): Use mbtowc() if it's available and
  if btowc() is not available.

-
Index: include/loc/_ctype.h
===
--- include/loc/_ctype.h(revision 581916)
+++ include/loc/_ctype.h(working copy)
@@ -541,7 +541,7 @@
 inline char
 ctype::narrow (char_type __c, char __dfault) const
 {
-const _RWSTD_SIZE_T __inx = _RWSTD_STATIC_CAST (unsigned char,
__c);
+const _RWSTD_SIZE_T __inx = __c;
 
 // optimize away all but the first call to the virtual do_widen()
 if (   __inx < sizeof _C_narrow_tab / sizeof *_C_narrow_tab
Index: src/wctype.cpp
===
--- src/wctype.cpp  (revision 581916)
+++ src/wctype.cpp  (working copy)
@@ -881,11 +881,12 @@
 const _RW::__rw_setlocale clocale (_C_name, LC_CTYPE);
 
 const int tmp = wctob (c);
+ch = _RWSTD_EOF == tmp ? dfault : char (tmp);
 
-ch = tmp < 0 ? dfault : char (tmp);
-
 #elif !defined (_RWSTD_NO_WCTOMB)
 
+const _RW::__rw_setlocale clocale (_C_name, LC_CTYPE);
+
 char tmp [_RWSTD_MB_LEN_MAX];
 ch = 1 == wctomb (tmp, c) ? *tmp : dfault;
 
@@ -1005,8 +1006,15 @@
 // prevent sign extension if `c' is negative
 ch = btowc (u_c);
 
-#else   // if defined (_RWSTD_NO_BTOWC)
+#elif !defined (_RWSTD_NO_MBTOWC)
 
+const _RW::__rw_setlocale clocale (_C_name, LC_CTYPE);
+
+char_type tmp;
+ch = 1 == mbtowc (&tmp, &c, 1) ? tmp : char_type (_RWSTD_WEOF);
+
+#else   // if defined (_RWSTD_NO_MBTOWC)
+
 ch = char_type (u_c);
 
 #endif   // _RWSTD_NO_BTOWC
-

Farid.

Re: [RFC] stdcxx acknowledgments

[Andrew Black]

Greetings all.

One thought that I have looking over the proposed patch is that it
doesn't include the names of people who have contribute code to the
release, but who aren't comitters.  Scott Zhong and Travis Vitek both
have changes attributed to them, but neither name appears in the list.
I suspect there are others, but it would require a search through the
change logs to locate the changes in question.

--Andrew Black

Martin Sebor wrote:
> In the patch attached to the issue Marc proposes to replace
> the names of the original Rogue Wave "contributors" to the
> project (which included support engineers as well management)
> with those of stdcxx committers (including Emeriti). I'd like
> to request people's opinion on this change. I personally am
> not entirely comfortable dropping all the contributors that
> predate stdcxx, although perhaps it may not be inappropriate
> (sorry for the double negative) to pare it down to people who
> contributed significant code and/or documentation changes).
> 
> What do others think?
> 
> Martin
> 
> Marc Betz (JIRA) wrote:
>>  [
>> https://issues.apache.org/jira/browse/STDCXX-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Marc Betz updated STDCXX-505:
>> -
>>
>> Attachment: (was: acknow.html)
>>
>>> Update the Acknowledgments page
>>> ---
>>>
>>> Key: STDCXX-505
>>> URL: https://issues.apache.org/jira/browse/STDCXX-505
>>> Project: C++ Standard Library
>>>  Issue Type: Sub-task
>>>  Components: Documentation
>>>Affects Versions: 4.1.2, 4.1.3, 4.1.4
>>>Reporter: Marc Betz
>>>Assignee: Marc Betz
>>> Fix For: 4.2
>>>
>>>
>>
>>
> 

[jira] Closed: (STDCXX-575) [MSVC] 22.locale.cons.mt fails

[Farid Zaripov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov closed STDCXX-575.



> [MSVC] 22.locale.cons.mt fails
> --
>
> Key: STDCXX-575
> URL: https://issues.apache.org/jira/browse/STDCXX-575
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Tests
> Environment: MSVC, ICC/Windows
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: 22.locale.cons.mt.cpp.diff
>
>
> The 22.locale.cons.mt test aborts on assert. The MSVC doesn't have the 
> LC_MESSAGES category and when the one locale combining with 
> std::locale::messages category from another locale the resulting locale is 
> equal to the source locale.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (STDCXX-575) [MSVC] 22.locale.cons.mt fails

[Farid Zaripov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov resolved STDCXX-575.
--

Resolution: Fixed

Fixed thus: http://svn.apache.org/viewvc?rev=581946&view=rev

> [MSVC] 22.locale.cons.mt fails
> --
>
> Key: STDCXX-575
> URL: https://issues.apache.org/jira/browse/STDCXX-575
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Tests
> Environment: MSVC, ICC/Windows
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: 22.locale.cons.mt.cpp.diff
>
>
> The 22.locale.cons.mt test aborts on assert. The MSVC doesn't have the 
> LC_MESSAGES category and when the one locale combining with 
> std::locale::messages category from another locale the resulting locale is 
> equal to the source locale.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (STDCXX-564) [MSVC] 64-bit conversion warnings building the library

[Farid Zaripov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov resolved STDCXX-564.
--

Resolution: Fixed

Fixed thus: http://svn.apache.org/viewvc?rev=581929&view=rev

> [MSVC] 64-bit conversion warnings building the library
> --
>
> Key: STDCXX-564
> URL: https://issues.apache.org/jira/browse/STDCXX-564
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: trunk
> Environment: MSVC 8.0 x64 platform
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: stdlib.patch
>
>
> These warnings I got when building the library with MSVC 8.0 / x64 platform:
> file.cpp
> $(TOPDIR)\src\file.cpp(484) : warning C4244: 'argument' : conversion from 
> '__int64' to 'long', possible loss of data
> $(TOPDIR)\src\file.cpp(493) : warning C4244: 'argument' : conversion from 
> '__int64' to 'long', possible loss of data
> $(TOPDIR)\src\file.cpp(508) : warning C4244: 'argument' : conversion from 
> 'unsigned __int64' to 'unsigned int', possible loss of data
> $(TOPDIR)\src\file.cpp(523) : warning C4244: 'argument' : conversion from 
> 'unsigned __int64' to 'unsigned int', possible loss of data
> locale_core.cpp
> $(TOPDIR)\src\locale_core.cpp(141) : warning C4267: 'argument' : conversion 
> from 'size_t' to 'int', possible loss of data
> num_put.cpp
> $(TOPDIR)\src\num_put.cpp(745) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(772) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(802) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(830) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> ti_num_get.cpp
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_punct.h(143) : see reference to function 
> template instantiation '__rw::__rw_istreambuf_iterator 
> __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const
>  char *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _CharT=char,
> _Traits=std::char_traits
> ]
> ti_wnum_get.cpp
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_punct.h(150) : see reference to function 
> template instantiation '__rw::__rw_wistreambuf_iterator 
> __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const
>  wchar_t *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _CharT=wchar_t,
> _Traits=std::char_traits
> ]
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_num_get.cc(218) : see reference to function 
> template instantiation '_InputIter 
> __rw::__rw_match_name>(_InputIter,_InputIter,const
>  _CharT *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _InputIter=std::istreambuf_iterator>,
> _CharT=char,
> _Traits=std::char_traits
> ]
> $(TOPDIR)\include\loc/_num_get.cc(172) : while compiling class 
> template member function 'std::istreambuf_iterator<_CharT,_Traits> 
> std::num_get<_CharT,_InputIter>::do_get(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,std::ios_base
>  &,__rw::__rw_iostate &,bool &) const'
> with
> [
> _CharT=char,
> _Traits=std::char_traits,
> _InputIter=std::istreambuf_iterator>
> ]
> $(TOPDIR)\include\loc/_locale.h(346) : see reference to class 
> template instantiation 'std::num_get<_CharT,_InputIter>' being compiled
> with
> [
> _CharT=char,
> _InputIter=std::istreambuf_iterator>
> ]
> $(TOPDIR)\include\loc/_locale.h(88) : see reference to function 
> template instantiation 'const __rw::__rw_facet 
> *__rw::__rw_get_facet<_Facet>(const std::locale &,const _Facet *)' being 
> compiled
> with
> [
> _Facet=std::numpunct
> ]

[jira] Closed: (STDCXX-564) [MSVC] 64-bit conversion warnings building the library

[Farid Zaripov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov closed STDCXX-564.



> [MSVC] 64-bit conversion warnings building the library
> --
>
> Key: STDCXX-564
> URL: https://issues.apache.org/jira/browse/STDCXX-564
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: trunk
> Environment: MSVC 8.0 x64 platform
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: stdlib.patch
>
>
> These warnings I got when building the library with MSVC 8.0 / x64 platform:
> file.cpp
> $(TOPDIR)\src\file.cpp(484) : warning C4244: 'argument' : conversion from 
> '__int64' to 'long', possible loss of data
> $(TOPDIR)\src\file.cpp(493) : warning C4244: 'argument' : conversion from 
> '__int64' to 'long', possible loss of data
> $(TOPDIR)\src\file.cpp(508) : warning C4244: 'argument' : conversion from 
> 'unsigned __int64' to 'unsigned int', possible loss of data
> $(TOPDIR)\src\file.cpp(523) : warning C4244: 'argument' : conversion from 
> 'unsigned __int64' to 'unsigned int', possible loss of data
> locale_core.cpp
> $(TOPDIR)\src\locale_core.cpp(141) : warning C4267: 'argument' : conversion 
> from 'size_t' to 'int', possible loss of data
> num_put.cpp
> $(TOPDIR)\src\num_put.cpp(745) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(772) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(802) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(830) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> ti_num_get.cpp
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_punct.h(143) : see reference to function 
> template instantiation '__rw::__rw_istreambuf_iterator 
> __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const
>  char *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _CharT=char,
> _Traits=std::char_traits
> ]
> ti_wnum_get.cpp
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_punct.h(150) : see reference to function 
> template instantiation '__rw::__rw_wistreambuf_iterator 
> __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const
>  wchar_t *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _CharT=wchar_t,
> _Traits=std::char_traits
> ]
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_num_get.cc(218) : see reference to function 
> template instantiation '_InputIter 
> __rw::__rw_match_name>(_InputIter,_InputIter,const
>  _CharT *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _InputIter=std::istreambuf_iterator>,
> _CharT=char,
> _Traits=std::char_traits
> ]
> $(TOPDIR)\include\loc/_num_get.cc(172) : while compiling class 
> template member function 'std::istreambuf_iterator<_CharT,_Traits> 
> std::num_get<_CharT,_InputIter>::do_get(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,std::ios_base
>  &,__rw::__rw_iostate &,bool &) const'
> with
> [
> _CharT=char,
> _Traits=std::char_traits,
> _InputIter=std::istreambuf_iterator>
> ]
> $(TOPDIR)\include\loc/_locale.h(346) : see reference to class 
> template instantiation 'std::num_get<_CharT,_InputIter>' being compiled
> with
> [
> _CharT=char,
> _InputIter=std::istreambuf_iterator>
> ]
> $(TOPDIR)\include\loc/_locale.h(88) : see reference to function 
> template instantiation 'const __rw::__rw_facet 
> *__rw::__rw_get_facet<_Facet>(const std::locale &,const _Facet *)' being 
> compiled
> with
> [
> _Facet=std::numpunct
> ]
> $(TOPDIR)\include\loc/_num_get.cc(196) : see reference to function 
> template

[jira] Updated: (STDCXX-564) [MSVC] 64-bit conversion warnings building the library

[Farid Zaripov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov updated STDCXX-564:
-

Attachment: stdlib.patch

Patch file updated.

> [MSVC] 64-bit conversion warnings building the library
> --
>
> Key: STDCXX-564
> URL: https://issues.apache.org/jira/browse/STDCXX-564
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: trunk
> Environment: MSVC 8.0 x64 platform
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: stdlib.patch
>
>
> These warnings I got when building the library with MSVC 8.0 / x64 platform:
> file.cpp
> $(TOPDIR)\src\file.cpp(484) : warning C4244: 'argument' : conversion from 
> '__int64' to 'long', possible loss of data
> $(TOPDIR)\src\file.cpp(493) : warning C4244: 'argument' : conversion from 
> '__int64' to 'long', possible loss of data
> $(TOPDIR)\src\file.cpp(508) : warning C4244: 'argument' : conversion from 
> 'unsigned __int64' to 'unsigned int', possible loss of data
> $(TOPDIR)\src\file.cpp(523) : warning C4244: 'argument' : conversion from 
> 'unsigned __int64' to 'unsigned int', possible loss of data
> locale_core.cpp
> $(TOPDIR)\src\locale_core.cpp(141) : warning C4267: 'argument' : conversion 
> from 'size_t' to 'int', possible loss of data
> num_put.cpp
> $(TOPDIR)\src\num_put.cpp(745) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(772) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(802) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(830) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> ti_num_get.cpp
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_punct.h(143) : see reference to function 
> template instantiation '__rw::__rw_istreambuf_iterator 
> __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const
>  char *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _CharT=char,
> _Traits=std::char_traits
> ]
> ti_wnum_get.cpp
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_punct.h(150) : see reference to function 
> template instantiation '__rw::__rw_wistreambuf_iterator 
> __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const
>  wchar_t *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _CharT=wchar_t,
> _Traits=std::char_traits
> ]
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_num_get.cc(218) : see reference to function 
> template instantiation '_InputIter 
> __rw::__rw_match_name>(_InputIter,_InputIter,const
>  _CharT *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _InputIter=std::istreambuf_iterator>,
> _CharT=char,
> _Traits=std::char_traits
> ]
> $(TOPDIR)\include\loc/_num_get.cc(172) : while compiling class 
> template member function 'std::istreambuf_iterator<_CharT,_Traits> 
> std::num_get<_CharT,_InputIter>::do_get(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,std::ios_base
>  &,__rw::__rw_iostate &,bool &) const'
> with
> [
> _CharT=char,
> _Traits=std::char_traits,
> _InputIter=std::istreambuf_iterator>
> ]
> $(TOPDIR)\include\loc/_locale.h(346) : see reference to class 
> template instantiation 'std::num_get<_CharT,_InputIter>' being compiled
> with
> [
> _CharT=char,
> _InputIter=std::istreambuf_iterator>
> ]
> $(TOPDIR)\include\loc/_locale.h(88) : see reference to function 
> template instantiation 'const __rw::__rw_facet 
> *__rw::__rw_get_facet<_Facet>(const std::locale &,const _Facet *)' being 
> compiled
> with
> [
> _Facet=std::numpunct
> ]
> $(TOPDIR)\include\loc/_num

[jira] Updated: (STDCXX-564) [MSVC] 64-bit conversion warnings building the library

[Farid Zaripov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov updated STDCXX-564:
-

Attachment: (was: stdlib.patch)

> [MSVC] 64-bit conversion warnings building the library
> --
>
> Key: STDCXX-564
> URL: https://issues.apache.org/jira/browse/STDCXX-564
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: trunk
> Environment: MSVC 8.0 x64 platform
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> These warnings I got when building the library with MSVC 8.0 / x64 platform:
> file.cpp
> $(TOPDIR)\src\file.cpp(484) : warning C4244: 'argument' : conversion from 
> '__int64' to 'long', possible loss of data
> $(TOPDIR)\src\file.cpp(493) : warning C4244: 'argument' : conversion from 
> '__int64' to 'long', possible loss of data
> $(TOPDIR)\src\file.cpp(508) : warning C4244: 'argument' : conversion from 
> 'unsigned __int64' to 'unsigned int', possible loss of data
> $(TOPDIR)\src\file.cpp(523) : warning C4244: 'argument' : conversion from 
> 'unsigned __int64' to 'unsigned int', possible loss of data
> locale_core.cpp
> $(TOPDIR)\src\locale_core.cpp(141) : warning C4267: 'argument' : conversion 
> from 'size_t' to 'int', possible loss of data
> num_put.cpp
> $(TOPDIR)\src\num_put.cpp(745) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(772) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(802) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> $(TOPDIR)\src\num_put.cpp(830) : warning C4244: 'argument' : conversion from 
> '__int64' to 'int', possible loss of data
> ti_num_get.cpp
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_punct.h(143) : see reference to function 
> template instantiation '__rw::__rw_istreambuf_iterator 
> __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const
>  char *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _CharT=char,
> _Traits=std::char_traits
> ]
> ti_wnum_get.cpp
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_punct.h(150) : see reference to function 
> template instantiation '__rw::__rw_wistreambuf_iterator 
> __rw::__rw_match_name>(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,const
>  wchar_t *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _CharT=wchar_t,
> _Traits=std::char_traits
> ]
> $(TOPDIR)\include\loc/_punct.cc(90) : warning C4334: '<<' : result of 32-bit 
> shift implicitly converted to 64 bits (was 64-bit shift intended?)
> $(TOPDIR)\include\loc/_num_get.cc(218) : see reference to function 
> template instantiation '_InputIter 
> __rw::__rw_match_name>(_InputIter,_InputIter,const
>  _CharT *const *,const unsigned __int64 *,unsigned __int64,unsigned __int64 
> &,int &,std::ios_base *)' being compiled
> with
> [
> _InputIter=std::istreambuf_iterator>,
> _CharT=char,
> _Traits=std::char_traits
> ]
> $(TOPDIR)\include\loc/_num_get.cc(172) : while compiling class 
> template member function 'std::istreambuf_iterator<_CharT,_Traits> 
> std::num_get<_CharT,_InputIter>::do_get(std::istreambuf_iterator<_CharT,_Traits>,std::istreambuf_iterator<_CharT,_Traits>,std::ios_base
>  &,__rw::__rw_iostate &,bool &) const'
> with
> [
> _CharT=char,
> _Traits=std::char_traits,
> _InputIter=std::istreambuf_iterator>
> ]
> $(TOPDIR)\include\loc/_locale.h(346) : see reference to class 
> template instantiation 'std::num_get<_CharT,_InputIter>' being compiled
> with
> [
> _CharT=char,
> _InputIter=std::istreambuf_iterator>
> ]
> $(TOPDIR)\include\loc/_locale.h(88) : see reference to function 
> template instantiation 'const __rw::__rw_facet 
> *__rw::__rw_get_facet<_Facet>(const std::locale &,const _Facet *)' being 
> compiled
> with
> [
> _Facet=std::numpunct
> ]
> $(TOPDIR)\include\loc/_num_get.cc(196) : see reference to function 
> temp

[jira] Resolved: (STDCXX-576) std::basic_streambuf<>::xsputn() incorrectly inserts the data, that is the part of the internal buffer

[Farid Zaripov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov resolved STDCXX-576.
--

Resolution: Fixed

Fixed thus: http://svn.apache.org/viewvc?rev=581871&view=rev

> std::basic_streambuf<>::xsputn() incorrectly inserts the data, that is the 
> part of the internal buffer
> --
>
> Key: STDCXX-576
> URL: https://issues.apache.org/jira/browse/STDCXX-576
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 27. Input/Output
>Affects Versions: trunk
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: 27.stringbuf.xsputn.stdcxx-576.cpp, sstream.cc.diff
>
>
> The test below aborts on assert. 
> test.cpp:
> -- 
> #include   // for stringbuf
> #include// for string
> #include   // for assert()
> struct PubBuf: std::stringbuf
> {
> char* Pbase () const { return this->pbase (); }
> };
> int main ()
> {
> // 512 is the default buffer size of the basic_stringbuf
> std::string s (512, 'a');
> std::stringbuf sbuf (s);
> PubBuf& buf = (PubBuf&)sbuf;
> std::streamsize res = buf.sputn (buf.Pbase (), 128);
> s.append (s.begin (), s.begin () + 128);
> const std::string& str = buf.str ();
> assert (res == 128);
> assert (str.size () == s.size ());
> assert (str == s);
> return 0;
> } 
> -- 
> The test output:
> --
> test: test.cpp:25: int main (): Assertion `str == s' failed.
> Aborted
> --

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (STDCXX-576) std::basic_streambuf<>::xsputn() incorrectly inserts the data, that is the part of the internal buffer

[Farid Zaripov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov closed STDCXX-576.



> std::basic_streambuf<>::xsputn() incorrectly inserts the data, that is the 
> part of the internal buffer
> --
>
> Key: STDCXX-576
> URL: https://issues.apache.org/jira/browse/STDCXX-576
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 27. Input/Output
>Affects Versions: trunk
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: 27.stringbuf.xsputn.stdcxx-576.cpp, sstream.cc.diff
>
>
> The test below aborts on assert. 
> test.cpp:
> -- 
> #include   // for stringbuf
> #include// for string
> #include   // for assert()
> struct PubBuf: std::stringbuf
> {
> char* Pbase () const { return this->pbase (); }
> };
> int main ()
> {
> // 512 is the default buffer size of the basic_stringbuf
> std::string s (512, 'a');
> std::stringbuf sbuf (s);
> PubBuf& buf = (PubBuf&)sbuf;
> std::streamsize res = buf.sputn (buf.Pbase (), 128);
> s.append (s.begin (), s.begin () + 128);
> const std::string& str = buf.str ();
> assert (res == 128);
> assert (str.size () == s.size ());
> assert (str == s);
> return 0;
> } 
> -- 
> The test output:
> --
> test: test.cpp:25: int main (): Assertion `str == s' failed.
> Aborted
> --

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-576) std::basic_streambuf<>::xsputn() incorrectly inserts the data, that is the part of the internal buffer

[Farid Zaripov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov updated STDCXX-576:
-

Attachment: 27.stringbuf.xsputn.stdcxx-576.cpp

The regression test added.

> std::basic_streambuf<>::xsputn() incorrectly inserts the data, that is the 
> part of the internal buffer
> --
>
> Key: STDCXX-576
> URL: https://issues.apache.org/jira/browse/STDCXX-576
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 27. Input/Output
>Affects Versions: trunk
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: 27.stringbuf.xsputn.stdcxx-576.cpp, sstream.cc.diff
>
>
> The test below aborts on assert. 
> test.cpp:
> -- 
> #include   // for stringbuf
> #include// for string
> #include   // for assert()
> struct PubBuf: std::stringbuf
> {
> char* Pbase () const { return this->pbase (); }
> };
> int main ()
> {
> // 512 is the default buffer size of the basic_stringbuf
> std::string s (512, 'a');
> std::stringbuf sbuf (s);
> PubBuf& buf = (PubBuf&)sbuf;
> std::streamsize res = buf.sputn (buf.Pbase (), 128);
> s.append (s.begin (), s.begin () + 128);
> const std::string& str = buf.str ();
> assert (res == 128);
> assert (str.size () == s.size ());
> assert (str == s);
> return 0;
> } 
> -- 
> The test output:
> --
> test: test.cpp:25: int main (): Assertion `str == s' failed.
> Aborted
> --

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-576) std::basic_streambuf<>::xsputn() incorrectly inserts the data, that is the part of the internal buffer

[Farid Zaripov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farid Zaripov updated STDCXX-576:
-

Attachment: sstream.cc.diff

The patch is attached.

> std::basic_streambuf<>::xsputn() incorrectly inserts the data, that is the 
> part of the internal buffer
> --
>
> Key: STDCXX-576
> URL: https://issues.apache.org/jira/browse/STDCXX-576
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 27. Input/Output
>Affects Versions: trunk
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: 27.stringbuf.xsputn.stdcxx-576.cpp, sstream.cc.diff
>
>
> The test below aborts on assert. 
> test.cpp:
> -- 
> #include   // for stringbuf
> #include// for string
> #include   // for assert()
> struct PubBuf: std::stringbuf
> {
> char* Pbase () const { return this->pbase (); }
> };
> int main ()
> {
> // 512 is the default buffer size of the basic_stringbuf
> std::string s (512, 'a');
> std::stringbuf sbuf (s);
> PubBuf& buf = (PubBuf&)sbuf;
> std::streamsize res = buf.sputn (buf.Pbase (), 128);
> s.append (s.begin (), s.begin () + 128);
> const std::string& str = buf.str ();
> assert (res == 128);
> assert (str.size () == s.size ());
> assert (str == s);
> return 0;
> } 
> -- 
> The test output:
> --
> test: test.cpp:25: int main (): Assertion `str == s' failed.
> Aborted
> --

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-576) std::basic_streambuf<>::xsputn() incorrectly inserts the data, that is the part of the internal buffer

[Farid Zaripov (JIRA)]

std::basic_streambuf<>::xsputn() incorrectly inserts the data, that is the part 
of the internal buffer
--

 Key: STDCXX-576
 URL: https://issues.apache.org/jira/browse/STDCXX-576
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 27. Input/Output
Affects Versions: trunk
 Environment: All
Reporter: Farid Zaripov
Assignee: Farid Zaripov
 Fix For: 4.2


The test below aborts on assert. 

test.cpp:
-- 
#include   // for stringbuf
#include// for string
#include   // for assert()

struct PubBuf: std::stringbuf
{
char* Pbase () const { return this->pbase (); }
};

int main ()
{
// 512 is the default buffer size of the basic_stringbuf
std::string s (512, 'a');

std::stringbuf sbuf (s);
PubBuf& buf = (PubBuf&)sbuf;

std::streamsize res = buf.sputn (buf.Pbase (), 128);
s.append (s.begin (), s.begin () + 128);

const std::string& str = buf.str ();

assert (res == 128);
assert (str.size () == s.size ());
assert (str == s);

return 0;
} 
-- 

The test output:
--
test: test.cpp:25: int main (): Assertion `str == s' failed.
Aborted
--


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: 22.locale.moneypunct test fails on MSVC

[Farid Zaripov]

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, October 03, 2007 11:21 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: 22.locale.moneypunct test fails on MSVC
> 
> Farid Zaripov wrote:
> >   The 22.locale.moneypunct test fails on MSVC (and 
> ICC/Windows) due to 
> > bug of the CRT or native API.
> > 
> >   The following program aborts on assert (tested on all MSVC's on 
> > Windows XP 32 and 64 bit). This program fails only for some 
> locales. 
> > So it fails with locname = "Catalan_Spain.1252"
> > but succeeds with locname = "Russian_Russia.1251".
> 
> Hmm. That makes the LC_MONETARY category pretty much unusable 
> on Windows. We need to open a bug with Microsoft and get this 
> fixed.

  Now I think that it's not a bug of the MSVC. My system locale is
Russian_Russia.1251 (codepage = 1251). When LC_MONETARY
id used, the unicode value of the euro sign is converted into 1251
codepage (using WideCharToMultiByte() API function). 

>From etc/nls/charmaps/CP1251 (/x88 == -120):
 /x88 EURO SIGN

  And when LC_ALL is used, the unicode value of the euro sign is
converted into 1252 codepage.

>From etc/nls/charmaps/CP1252 (/x80 == -128):
 /x80 EURO SIGN

  The std::moneypunct<> facet uses setlocale (LC_ALL, ) when initializes
the facet data, so I think the 22.locale.moneypunct.cpp test should use
setlocale (LC_ALL, ) instead of setlocale (LC_MONETARY, ), or use
setlocale (LC_CTYPE, ) before setlocale (LC_MONETARY, )..

Farid.