[jira] Updated: (STDCXX-413) 22.locale.money.get.cpp doesn't test international monetary formats

[Travis Vitek (JIRA)]

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

Travis Vitek updated STDCXX-413:


Attachment: money.get.patch

2007-08-28 Travis Vitek <[EMAIL PROTECTED]>

STDCXX-413
22.locale.money.get (do_test): move intl param to front of param
list to avoid modifying many lines of code unnecessarily.
(test_get): update to support testing international money format,
add overload to test both local and international money formats.



> 22.locale.money.get.cpp doesn't test international monetary formats
> ---
>
> Key: STDCXX-413
> URL: https://issues.apache.org/jira/browse/STDCXX-413
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 4.1.3
>Reporter: Mark Brown
>Assignee: Travis Vitek
> Fix For: 4.2
>
> Attachments: money.get.patch
>
>
> The test 22.locale.money.get.cpp doesn't exercise international monetary 
> formats. See:
> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sat, 12 May 2007 15:42:16 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r537492 - 
> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html
> Mark Brown wrote:
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> Sent: Sat, 12 May 2007 14:09:34 -0600
> >> To: stdcxx-dev@incubator.apache.org
> >> Subject: Re: svn commit: r537492 -
> >> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html
> >>
> >> Mark Brown wrote:
> >>> Martin,
> >>>
> >>> Thanks for fixing it! I have a question about the new code: Could you
> >>> show an example of an international monetary string that would be
> >>> correctly parsed by the facet? I tried a few but none of them could be
> >>> parsed. For instance, "USD 1234" gives this output:
> >>> USD 1234 --> "" --> 0
> >>> The same happens with g++ and STLport so I suspect I must be doing
> >>> something wrong. Removing the space between the currency symbol and the
> >>> number didn't make a difference.
> >> Hmm, I guess I should have tested the internationalized behavior before
> >> I put it in. I think the code is correct as is and your input should be
> >> correctly parsed by the facet (and produce 1234 on output). I'm not sure
> >> what's going on. Stepping through the code it looks like the money_get
> >> facet ends up retrieving the wrong specialization of moneypunct, i.e.,
> >> moneypunct when it needs moneypunct. What's
> >> puzzling is that both libstdc++ and STLport behave the same. It seems
> >> like too much of a coincidence for all three implementations to suffer
> >> from the same bug.
> >>
> >> In any event, thanks for bringing it to our attention! Can you open an
> >> issue for this as well so we don't forget to investigate it in case I
> >> don't get around to it soon?
> > 
> > I can certainly do that. I should also mention that while investigating 
> > this problem I found a test that's supposed to test this functionality: 
> > 22.locale.money.get.cpp. The test fails 20 out of 1934 assertions but none 
> > of them look like they have anything to do with parsing international 
> > monetary values. It doesn't look like they are being tested at all...
> Yeah, I noticed it too. I'm in the process of enhancing the test to
> exercise the international formats as well. If you don't mind creating
> another issue for the test, just for tracking purposes, that would be
> swell!
> Martin

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

[jira] Updated: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds

[Martin Sebor (JIRA)]

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

Martin Sebor updated STDCXX-507:


Summary: [Cygwin] Access violation while loading libstdxxx.dll in dynamic 
builds  (was: Access violation while loading libstdxxx.dll in dynamic builds on 
Cygwin)

Added a platform tag to the Summary to make the issue easier to find.

> [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
> ---
>
> Key: STDCXX-507
> URL: https://issues.apache.org/jira/browse/STDCXX-507
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 4.2
> Environment: gcc 3.4.4/Cygwin
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
> Attachments: localedef.imports
>
>
> Many utilities, examples and tests failed to start due to access violation 
> while loading libstdxxx.dll. In night builds logs they all finished with 
> status 5. The reason is access violation while loading libstdxxx.dll. All of 
> them has many times duplicated imports (see the attached file) and I suppose 
> that bug in ld utility.
> 
> $ ./localedef || echo $?
> 5
> $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef
> --- Process 732, exception C005 at 7C919994
> --- Process 732, exception C005 at 7C964ED1
> 

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

[jira] Closed: (STDCXX-338) [Cygwin] linker errors due to multiple definition of `std::exception::what()'

[Martin Sebor (JIRA)]

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

Martin Sebor closed STDCXX-338.
---

Resolution: Fixed

Looks like this has been fixed, although we still have STDCXX-507 to deal with. 
But that's a different problem altogether.

> [Cygwin] linker errors due to multiple definition of `std::exception::what()'
> -
>
> Key: STDCXX-338
> URL: https://issues.apache.org/jira/browse/STDCXX-338
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 4.1.3
> Environment: Cygwin
>Reporter: Mark Brown
>Assignee: Martin Sebor
> Fix For: 4.2
>
>
> When linking with stdcxx on Cygwin I get errors like:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x80): 
> multiple definition of `std::exception::what() const' 
> The config.log file shows these errors for the EXCEPTION_WHAT test:
> gcc -c -pedantic -nostdinc++ -g  -Wall -W -Wcast-qual -Winline -Wshadow 
> -Wwrite-strings -Wno-long-long -Wcast-align -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG 
> -I. /build
> /sebor/stdcxx-4.1.3/etc/config/src/EXCEPTION_WHAT.cpp
> In file included from 
> /home/mbrown/stdcxx-4.1.3/etc/config/src/EXCEPTION_WHAT.cpp:10:
> /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:83: 
> warning: `class std::exception' has virtual functions but non-virtual 
> destructor
> /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:333: 
> warning: unused parameter 'rhs'
> /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:388: 
> warning: unused parameter 'rhs'
> gcc EXCEPTION_WHAT.o   -lm -lsupc++ -o EXCEPTION_WHAT
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x0): 
> multiple definition of `std::exception::~exception()'
> EXCEPTION_WHAT.o:/home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:(.text$_ZNSt9exceptionD2Ev[std::exception::~exception()]+0x0):
>  first defined here
> collect2: ld returned 1 exit status

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

[jira] Closed: (STDCXX-446) [gcc] warning: inlining failed on operator<<(ostream&, complex)

[Martin Sebor (JIRA)]

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

Martin Sebor closed STDCXX-446.
---

Resolution: Fixed

Nightly builds are free of the warning.

> [gcc] warning: inlining failed on operator<<(ostream&, complex)
> ---
>
> Key: STDCXX-446
> URL: https://issues.apache.org/jira/browse/STDCXX-446
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 26. Numerics
>Affects Versions: 4.1.3
> Environment: gcc 4.1.1
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>Priority: Minor
> Fix For: 4.2
>
>
> The warnings below suggest that the complex insertion operrator is too big 
> for inlining...
> gcc -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include -I$(BUILDDIR)/include 
> -I$(TOPDIR)/examples/include  -pedantic -nostdinc++ -O2  -m32 -W -Wall 
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   
> $(TOPDIR)/examples/manual/complex.cpp
> $(TOPDIR)/include/complex: In function 'int main()':
> $(TOPDIR)/include/complex:935: warning: inlining failed in call to 
> 'std::basic_ostream<_CharT, _Traits>& 
> std::operator<<(std::basic_ostream<_CharT, _Traits>&, const 
> std::complex<_TypeT>&) [with _TypeT = double, _CharT = char, _Traits = 
> std::char_traits]': --param max-inline-insns-single limit reached
> $(TOPDIR)/examples/manual/complex.cpp:41: warning: called from here
> $(TOPDIR)/include/complex:935: warning: inlining failed in call to 
> 'std::basic_ostream<_CharT, _Traits>& 
> std::operator<<(std::basic_ostream<_CharT, _Traits>&, const 
> std::complex<_TypeT>&) [with _TypeT = double, _CharT = char, _Traits = 
> std::char_traits]': --param max-inline-insns-single limit reached
> $(TOPDIR)/examples/manual/complex.cpp:41: warning: called from here

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

[jira] Closed: (STDCXX-447) [gcc] warning: inlining failed on std::pow (std::complex, std::complex)

[Martin Sebor (JIRA)]

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

Martin Sebor closed STDCXX-447.
---

Resolution: Fixed

Nightly builds are free of the warnings.

> [gcc] warning: inlining failed on std::pow (std::complex, std::complex)
> ---
>
> Key: STDCXX-447
> URL: https://issues.apache.org/jira/browse/STDCXX-447
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 26. Numerics
>Affects Versions: 4.1.3
> Environment: gcc 4.1.1
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>Priority: Minor
> Fix For: 4.2
>
>
> The warnings below suggest that the std::pow() overfload for complex might be 
> too big to be successfully inlined...
> gcc -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include -I$(BUILDDIR)/include 
> -I$(TOPDIR)/tests/include  -pedantic -nostdinc++ -O2  -m32 -W -Wall 
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   
> $(TOPDIR)/tests/numerics/26_complex.cpp
> $(TOPDIR)/include/complex: In member function 'void 
> RWQEComplexTest::testPow() [with T = double]':
> $(TOPDIR)/include/complex:814: warning: inlining failed in call to 
> 'std::complex<_TypeT> std::pow(const std::complex<_TypeT>&, const 
> std::complex<_TypeT>&) [with _TypeT = double]': --param large-function-growth 
> limit reached
> $(TOPDIR)/include/complex:759: warning: called from here
> $(TOPDIR)/include/complex:814: warning: inlining failed in call to 
> 'std::complex<_TypeT> std::pow(const std::complex<_TypeT>&, const 
> std::complex<_TypeT>&) [with _TypeT = double]': --param large-function-growth 
> limit reached
> $(TOPDIR)/include/complex:759: warning: called from here
> $(TOPDIR)/include/complex:814: warning: inlining failed in call to 
> 'std::complex<_TypeT> std::pow(const std::complex<_TypeT>&, const 
> std::complex<_TypeT>&) [with _TypeT = double]': --param large-function-growth 
> limit reached
> $(TOPDIR)/include/complex:759: warning: called from here
> $(TOPDIR)/include/complex: In member function 'void 
> RWQEComplexTest::testPow() [with T = long double]':
> $(TOPDIR)/include/complex:814: warning: inlining failed in call to 
> 'std::complex<_TypeT> std::pow(const std::complex<_TypeT>&, const 
> std::complex<_TypeT>&) [with _TypeT = long double]': --param 
> large-function-growth limit reached
> $(TOPDIR)/include/complex:759: warning: called from here
> $(TOPDIR)/include/complex:814: warning: inlining failed in call to 
> 'std::complex<_TypeT> std::pow(const std::complex<_TypeT>&, const 
> std::complex<_TypeT>&) [with _TypeT = long double]': --param 
> large-function-growth limit reached
> $(TOPDIR)/include/complex:759: warning: called from here
> $(TOPDIR)/include/complex:814: warning: inlining failed in call to 
> 'std::complex<_TypeT> std::pow(const std::complex<_TypeT>&, const 
> std::complex<_TypeT>&) [with _TypeT = long double]': --param 
> large-function-growth limit reached
> $(TOPDIR)/include/complex:759: warning: called from here
> $(TOPDIR)/include/complex:814: warning: inlining failed in call to 
> 'std::complex<_TypeT> std::pow(const std::complex<_TypeT>&, const 
> std::complex<_TypeT>&) [with _TypeT = long double]': --param 
> large-function-growth limit reached
> $(TOPDIR)/include/complex:799: warning: called from here
> $(TOPDIR)/include/complex:814: warning: inlining failed in call to 
> 'std::complex<_TypeT> std::pow(const std::complex<_TypeT>&, const 
> std::complex<_TypeT>&) [with _TypeT = long double]': --param 
> large-function-growth limit reached
> $(TOPDIR)/tests/numerics/26_complex.cpp:810: warning: called from here
> $(TOPDIR)/include/complex:814: warning: inlining failed in call to 
> 'std::complex<_TypeT> std::pow(const std::complex<_TypeT>&, const 
> std::complex<_TypeT>&) [with _TypeT = long double]': --param 
> large-function-growth limit reached
> $(TOPDIR)/tests/numerics/26_complex.cpp:818: warning: called from here
> $(TOPDIR)/include/iosfwd: In member function 'void 
> RWQEComplexTest::testStreamOperator() [with T = long double]':
> $(TOPDIR)/include/iosfwd:162: warning: inlining failed in call to 'virtual 
> std::basic_ifstream >::~basic_ifstream()': 
> --param large-function-growth limit reached
> $(TOPDIR)/tests/numerics/26_complex.cpp:530: warning: called from here
> $(TOPDIR)/include/complex:892: warning: inlining failed in call to 
> 'std::basic_istream<_CharT, _Traits>& 
> std::operator>>(std::basic_istream<_CharT, _Traits>&, std::complex<_TypeT>&) 
> [with _TypeT = long double, _CharT = char, _Traits = 
> std::char_traits]': --param large-function-growth limit reached
> $(TOPDIR)/tests/numerics/26_complex.cpp:508: warning: called from here
> $(TOPDIR)/include/complex:892: warning: inlining failed in call to 
> 'std::basic_istream<_CharT, _Traits>& 
> std:

[jira] Commented: (STDCXX-509) std::numeric_limits::infinity() depends on dynamic initialization

[Martin Sebor (JIRA)]

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

Martin Sebor commented on STDCXX-509:
-

Looks like the committed change is binary compatible (see the post below) and 
so it's not appropriate for 4.2. We need a different solution for this release.

http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg04613.html

> std::numeric_limits::infinity() depends on dynamic initialization
> -
>
> Key: STDCXX-509
> URL: https://issues.apache.org/jira/browse/STDCXX-509
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 18. Language Support
>Affects Versions: 4.1.2, 4.1.3
> Environment: gcc3.2, linux AS3.0
>Reporter: Ravi K Inampudi
>Assignee: Martin Sebor
> Fix For: 4.2
>
> Attachments: limits_bits.cpp.patch
>
>
> A customer discovered a problem with std::numeric_limits in RW 
> libstd. Placing RW libstd on linkline *before* libFoo results in the program 
> printing "0" instead of "inf". The problem doesn't happen with native gcc STL.
> We reproduced the problem with the latest version of standard library 
> downloaded from Apache. From our understanding, when creating the libFoo.so 
> and using the native standard library is creating an implicit dependency on 
> the libsupc++ (compiler dependent). This implicit dependency is initializing 
> the static variable when libFoo.so is loaded. If we use RW libstd instread of 
> libstdc++(native gcc stl), the program will print "0" instead of "inf".
>  # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread 
> -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include 
> -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include 
> -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic 
> -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings 
> -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C 
>  # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib 
> -lstd12d -lsupc++ -lm -lFooRW 
> However, using the RW standard library, if such dependency is created 
> explicitly then it prints "inf". For example, the following set of commands 
> fixes the problem:
>  # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread 
> -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include 
> -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include 
> -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic 
> -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings 
> -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C -lstd12d
>  # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib 
> -lstd12d -lsupc++ -lm -lFooRW 
> But the customer never links their shared libs(i.e libFoo in this example) 
> with RW libstd.  They only link binaries with RW libstd! But it makes RW 
> libstd sensitive to link order. And they think the problem is in limits.cpp 
> file:
> > 
> > static union {
> > char _C_bits [sizeof (double)];
> > double _C_inf;
> > } __rw_dbl_inf_bits = { _RWSTD_DBL_INF_BITS };
> >
> > _RWSTD_EXPORT extern const double __rw_dbl_infinity =
> > __rw_dbl_inf_bits._C_inf; 
> >
> > __rw_dbl_infinity ends up in the uninitialized data section of
> > libstd_gcc32.so
> >
> > nm -C libstd_gcc32.so| grep __rw_dbl_infinity
> > 000937f8 B __rw::__rw_dbl_infinity
> >
> If the symbol was initialized in data section, the link order wouldn't matter.
> Environment: RWSP6, gcc3.2, linux AS3.0
> Martin Sebor's Comments:
> Because the initializer of __rw_dbl_infinity is not a constant expresssion 
> [expr.const] the symbol is initialized dynamically (at runtime) rather than 
> statically (i.e., at load time). It seems that the compiler should be able to 
> initialize it statically anyway, even if it's not required to. Regardless, we 
> should avoid making the assumption that it will and change the initialization 
> of the extern constants to use constant expressions instead.

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

Re: Fwd: Re: svn commit: r564059 - in /incubator/stdcxx/trunk: include/limits src/limits_bits.cpp

[Martin Sebor]

Mark Brown wrote:

For some reason this post bounced. It's probably my fault for using two
email accounts. I should use the same one.


I think I saw an email about the Apache infrastructure having
some issues recently so it's possible that your post got dropped
as a result. Thanks for following up!

The change was supposed to be binary compatible -- 4.2 is meant
to be binary compatible with 4.1.3. Changing the language linkage
of the helper constants from "C++" to "C" to work around the MSVC
mangling "feature" (unlike other compilers, MSVC mangles the type
of objects into their names) caused them to lose the namespace
prefix and broke binary compatibility. I'll need to go back and
devise a different solution.

Thanks again for pointing it out! It underscores how easy it
is to break binary compatibility and how badly we need to test
for such breakage.

Martin



-- Mark

-- Forwarded message --
From: mark.g.brown <[EMAIL PROTECTED]>
Date: Aug 14, 2007 11:09 PM
Subject: Re: Re: svn commit: r564059 - in /incubator/stdcxx/trunk:
include/limits src/limits_bits.cpp
To: stdcxx-dev@incubator.apache.org

Martin Sebor wrote:

Andrew Black wrote:

Greetings Martin

I'm not completely certain, but I believe this change is leading to
failures on most or all operating systems.  In particular, linker
warnings of

Drat! The patch is incomplete. I forgot to commit a change
to another library file that forward declares the symbol.
This should fix it:
http://svn.apache.org/viewvc?view=rev&rev=564664


I'm curious, is this change meant to be binary compatible? I ask because
some of my programs have started to fail to link since I updated to the
latest stdcxx sources.

-- Mark


Thanks for letting me know!
Martin


ld: (Warning) Unsatisfied symbol "__rw::__rw_flt_infinity" in file
$(BUILDDIR)/lib/libstd.sl
ld: (Warning) Unsatisfied symbol "__rw::__rw_dbl_infinity" in file
$(BUILDDIR)/lib/libstd.sl
ld: (Warning) Unsatisfied symbol "__rw::__rw_ldbl_infinity" in file
$(BUILDDIR)/lib/libstd.sl

are observed in static builds (on HPUX), and the same message is
observed when running the exec utility in dynamic builds.

--Andrew Black

[EMAIL PROTECTED] wrote:

Author: sebor
Date: Wed Aug  8 17:47:54 2007
New Revision: 564059

URL: http://svn.apache.org/viewvc?view=rev&rev=564059
Log:
2007-08-09  Martin Sebor  <[EMAIL PROTECTED]>

STDCXX-509
* limits (__rw_flt_denorm_min, __rw_flt_infinity, __rw_flt_qNaN,
__rw_flt_sNaN, __rw_dbl_denorm_min, __rw_dbl_infinity,
__rw_dbl_qNaN,
__rw_dbl_sNaN, __rw_ldbl_denorm_min, __rw_ldbl_infinity,
__rw_ldbl_qNaN,
__rw_ldbl_sNaN): Declared floating point constants with "C" language
linkage to prevent "clever" compilers such as MSVC from mangling
their
type into their names and to permit them to be defined with
different
types.
* limits_bits.cpp (__rw_flt_denorm_min, __rw_flt_infinity,
__rw_flt_qNaN, __rw_flt_sNaN, __rw_dbl_denorm_min,
__rw_dbl_infinity,
__rw_dbl_qNaN, __rw_dbl_sNaN, __rw_ldbl_denorm_min,
__rw_ldbl_infinity,
__rw_ldbl_qNaN, __rw_ldbl_sNaN): Defined as statically (i.e., at
load
time as opposed to dynamically, at runtime) initialized unions,
backed
by the appropriate byte patterns, with "C" language linkage to
permit
the defintions to have a different type than the declarations.
(__rw_flt_denorm_min_bits, __rw_flt_infinity_bits,
__rw_flt_qNaN_bits,
__rw_flt_sNaN_bits, __rw_dbl_denorm_min_bits,
__rw_dbl_infinity_bits,
__rw_dbl_qNaN_bits, __rw_dbl_sNaN_bits, __rw_ldbl_denorm_min_bits,
__rw_ldbl_infinity_bits, __rw_ldbl_qNaN_bits,  __rw_ldbl_sNaN_bits):
Removed.

Modified:
incubator/stdcxx/trunk/include/limits
incubator/stdcxx/trunk/src/limits_bits.cpp

Modified: incubator/stdcxx/trunk/include/limits
URL:


http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/limits?view=diff&rev=564059&r1=564058&r2=564059



==

--- incubator/stdcxx/trunk/include/limits (original)
+++ incubator/stdcxx/trunk/include/limits Wed Aug  8 17:47:54 2007
@@ -23,7 +23,7 @@
  * implied.   See  the License  for  the  specific language  governing
  * permissions and limitations under the License.
  *
- * Copyright 1994-2006 Rogue Wave Software.
+ * Copyright 1994-2007 Rogue Wave Software, Inc.
  *


**/


@@ -86,7 +86,9 @@
 #endif   // _RWSTD_IS_IEC559


-_RWSTD_NAMESPACE (__rw) { +_RWSTD_NAMESPACE (__rw) {
+
+extern "C" {

 _RWSTD_EXPORT extern const float   __rw_flt_infinity;
 _RWSTD_EXPORT extern const double  __rw_dbl_infinity;
@@ -108,6 +110,8 @@
 _RWSTD_EXPORT extern const long double __rw_ldbl_denorm_min;

 #endif   // _RWSTD_NO_LONG_DOUBLE
+
+}   // extern "C"

 }   // namespace __rw


Modified: incubator/stdcxx/trunk/src/limits_bits.cpp
URL:


http://svn.apache.org/viewvc/incubator/stdcxx/trunk/src/limits_bits.cpp?view=diff&rev=564059&r1=564058&r2

[jira] Updated: (STDCXX-540) [localedef] illegal multibyte prefix '\x90' in character map file on CP1255

[Martin Sebor (JIRA)]

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

Martin Sebor updated STDCXX-540:


Fix Version/s: (was: 4.2)
   4.2.1

Scheduled for 4.2.1.

> [localedef] illegal multibyte prefix '\x90' in character map file on CP1255
> ---
>
> Key: STDCXX-540
> URL: https://issues.apache.org/jira/browse/STDCXX-540
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 4.1.3
>Reporter: Martin Sebor
>Priority: Minor
> Fix For: 4.2.1
>
>
> The localedef utility has trouble processing the CP1255 character set 
> description file:
> $ (export RWSTD_SRC_ROOT=/nfs/devco/sebor/stdcxx/etc/nls; \
> mkdir -p /tmp/$$ \
> && ./localedef -w -c -f $RWSTD_SRC_ROOT/charmaps/CP1255 -i 
> $RWSTD_SRC_ROOT/src/yi_US /tmp/$$/yi_US.CP1255)
> Error 308: illegal multibyte prefix '\x90' in character map file

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

[jira] Updated: (STDCXX-449) [ITC/Linux] std::string Write -> Read data-race errors

[Martin Sebor (JIRA)]

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

Martin Sebor updated STDCXX-449:


 Priority: Minor  (was: Critical)
Affects Version/s: 4.1.2
   4.1.4
Fix Version/s: 4.2.1

I think these are benign, at least on x86 and x86_64, since the code has been 
there for eons and the string thread safety tests have been passing, but I'll 
leave it open so that when we have a bit more time in the 4.2.1 release cycle 
we can do a better analysis. At the very least we can silence the ITC errors as 
false positives. Bumped down Priority to Minor and scheduled for 4.2.1.

> [ITC/Linux] std::string Write -> Read data-race errors
> --
>
> Key: STDCXX-449
> URL: https://issues.apache.org/jira/browse/STDCXX-449
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2
> Environment: Intel Thread Checker 3.1 on Red Hat Enterprise Linux AS 
> release 4 (Nahant Update 4)
>Reporter: Martin Sebor
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: 21.string.cons.mt.itc-report.html
>
>
> Running the Intel Thread Checker on the string thread safety tests 
> 21.string.cons.mt and 21.string.push_back.mt produces errors suggesting 
> potential thread safety problems even though the tests run successfully to 
> completion. See the text output below:
> $ tcheck_cl -w 200 ./21.string.cons.mt --nloops=100 --nthreads=2
> Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
> Copyright (c) 2007 Intel Corporation. All rights reserved.
> Building project
> Running:  /build/sebor/stdcxx-icc-9.1_042-15s/tests/21.string.cons.mt 
> --nloops=100 --nthreads=2
> # INFO (S1) (10 lines):
> # TEXT: 
> # COMPILER: Intel C++, __INTEL_COMPILER = 910, __INTEL_COMPILER_BUILD_DATE = 
> 20060706, __EDG_VERSION__ = 306
> # ENVIRONMENT: i386 running linux-elf 2.4.20 with glibc 2.3
> # FILE: 21.string.cons.mt.cpp
> # COMPILED: Jun 13 2007, 13:00:49
> # COMMENT: thread safety
> 
> # CLAUSE: lib.string.cons
> # INFO (S1) (3 lines):
> # TEXT: testing std::string with 2 threads, 100 iterations each
> # CLAUSE: lib.string.cons
> # INFO (S1) (3 lines):
> # TEXT: testing std::wstring with 2 threads, 100 iterations each
> # CLAUSE: lib.string.cons
> # +---+--+--+--+
> # | DIAGNOSTIC|  ACTIVE  |   TOTAL  | INACTIVE |
> # +---+--+--+--+
> # | (S1) INFO |3 |3 |   0% |
> # | (S7) ASSERTION|0 |   16 | 100% |
> # +---+--+--+--+
> Application finished
> 
> |ID |Short Description|Severity   |Cou|Context[Best]  |Description
>  
> |1st Access[Best]|2nd Access[Best]  |
> |   | |Name   |nt |   |   
>  
> ||  |
> 
> |1  |Write -> Read|Error  |128|[21.string.cons.mt,|Memory read at 
> "_strref.h":159 conflicts with a prior memory write at [21.string.cons.mt,   
> |[21.string.cons.mt, |"_strref.h":159   |
> |   |data-race|   |   |0xadf0]|0x3475f] (flow 
> dependence)  
> |0x3475f]|  |
> 
> |2  |Read -> Write|Error  |5  |[21.string.cons.mt,|Memory write 
> at [21.string.cons.mt, 0x3475f] conflicts with a prior memory read at 
>  |"_strref.h":159 |[21.string.cons.mt,   |
> |   |data-race|   |   |0x34755]   
> |"_strref.h":159 (anti dependence)
>||0x3475f]  |
> __

[jira] Reopened: (STDCXX-233) std::strstreambuf::seekpos() fails to properly position get sequence

[Martin Sebor (JIRA)]

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

Martin Sebor reopened STDCXX-233:
-


Fixed is not the right resolution.

> std::strstreambuf::seekpos() fails to properly position get sequence
> 
>
> Key: STDCXX-233
> URL: https://issues.apache.org/jira/browse/STDCXX-233
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 27. Input/Output
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>
> Moved from the Rogue Wave bug tracking database:
> Created By: sebor @ Jul 01, 2000 08:28:15 PM
> This program fails with exit status of 1. It exits successfully (with 0) when 
> std::strstreambuf is replaced with std::stringbuf. I don't see anything in 
> D.7.1 that would require this behavior. Looks like a bug...
> The (enhanced) regress/test_bug10430.cpp exercises this bug and fails as a 
> result.
> #include 
> int main ()
> {
> std::strstreambuf sb;
> sb.sputn ("a", 1);
> sb.pubseekpos (0);
> char buf[2] = { 'X', 'Y' };
> return !(   1 == sb.sgetn (buf, sizeof buf)
>  && 'a' == buf [0] && 'Y' == buf [1]);
> }
> Modified By: sebor @ Nov 28, 2000 10:09:20 PM
> $ cat test_bug10430.out
> ## ---
> ## TestTag = RWQETest test_bug10430
> ## CompilerId  = g++-2.95.2
> ## MachineId   = SunOS killer 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-4
> ## Remark  = 
> ## RunTag  = test_bug10430 regression test
> ## FunctionTag = Issue #10430 -- streambufs delete passed in buffers.
> ##StepTag = stringbuf
> ##StepTag = filebuf
> ##StepTag = wstringstream
> ##StepTag = wfilebuf
> ##StepTag = strstreambuf
> ## -   AssertionTag = strstreambuf::sgetn ("", 11) == 11 (got 11)
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 102
> ## -   AssertionTag = strstreambuf::sgetn ("", 11); expected "0123456789"
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 107
> ## -   AssertionTag = strstreambuf::setbuf (0, 0) must have no effect
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 113
> ## -   AssertionTag = strstreambuf::sgetn ("", 11) == 11 (got 0)
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 121
> ## -   AssertionTag = strstreambuf::sgetn ("", 11); expected "0123456789"
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 126
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 1) must fail
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 133
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 1) must succeed
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 142
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 12) must succeed
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 151
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 22) must succeed
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 160
> ## Assertions = 75
> ## FailedAssertions = 9

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

[jira] Closed: (STDCXX-233) std::strstreambuf::seekpos() fails to properly position get sequence

[Martin Sebor (JIRA)]

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

Martin Sebor closed STDCXX-233.
---

Resolution: Cannot Reproduce

Unable to reproduce with the latest trunk.

> std::strstreambuf::seekpos() fails to properly position get sequence
> 
>
> Key: STDCXX-233
> URL: https://issues.apache.org/jira/browse/STDCXX-233
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 27. Input/Output
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>
> Moved from the Rogue Wave bug tracking database:
> Created By: sebor @ Jul 01, 2000 08:28:15 PM
> This program fails with exit status of 1. It exits successfully (with 0) when 
> std::strstreambuf is replaced with std::stringbuf. I don't see anything in 
> D.7.1 that would require this behavior. Looks like a bug...
> The (enhanced) regress/test_bug10430.cpp exercises this bug and fails as a 
> result.
> #include 
> int main ()
> {
> std::strstreambuf sb;
> sb.sputn ("a", 1);
> sb.pubseekpos (0);
> char buf[2] = { 'X', 'Y' };
> return !(   1 == sb.sgetn (buf, sizeof buf)
>  && 'a' == buf [0] && 'Y' == buf [1]);
> }
> Modified By: sebor @ Nov 28, 2000 10:09:20 PM
> $ cat test_bug10430.out
> ## ---
> ## TestTag = RWQETest test_bug10430
> ## CompilerId  = g++-2.95.2
> ## MachineId   = SunOS killer 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-4
> ## Remark  = 
> ## RunTag  = test_bug10430 regression test
> ## FunctionTag = Issue #10430 -- streambufs delete passed in buffers.
> ##StepTag = stringbuf
> ##StepTag = filebuf
> ##StepTag = wstringstream
> ##StepTag = wfilebuf
> ##StepTag = strstreambuf
> ## -   AssertionTag = strstreambuf::sgetn ("", 11) == 11 (got 11)
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 102
> ## -   AssertionTag = strstreambuf::sgetn ("", 11); expected "0123456789"
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 107
> ## -   AssertionTag = strstreambuf::setbuf (0, 0) must have no effect
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 113
> ## -   AssertionTag = strstreambuf::sgetn ("", 11) == 11 (got 0)
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 121
> ## -   AssertionTag = strstreambuf::sgetn ("", 11); expected "0123456789"
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 126
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 1) must fail
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 133
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 1) must succeed
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 142
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 12) must succeed
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 151
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 22) must succeed
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 160
> ## Assertions = 75
> ## FailedAssertions = 9

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

[jira] Updated: (STDCXX-372) locale test failure for br_FR.ISO-8859-1 and hu_HU.ISO-8859-2

[Martin Sebor (JIRA)]

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

Martin Sebor updated STDCXX-372:


 Priority: Minor  (was: Major)
Fix Version/s: 4.2.1

This is a Minor problem. Scheduled for 4.2.1.

> locale test failure for br_FR.ISO-8859-1 and hu_HU.ISO-8859-2
> -
>
> Key: STDCXX-372
> URL: https://issues.apache.org/jira/browse/STDCXX-372
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Locales
>Affects Versions: 4.2
> Environment: gcc 3.4.6, Linux x86_64
>Reporter: Martin Sebor
>Priority: Minor
> Fix For: 4.2.1
>
>
> Running the test scripts for br_FR.ISO-8859-1 and hu_HU.ISO-8859-2 shows that 
> stages 2 and 3 differ (the diff is below the script output):
> $ ./br_FR.ISO-8859-1.sh -d -n
> RWSTD_SRC_ROOT=/amd/devco/sebor/stdcxx/etc/nls
> export RWSTD_SRC_ROOT
> mkdir -p /tmp/locale.11871/stage.1/charmaps
> ./localedef -w -c -f /amd/devco/sebor/stdcxx/etc/nls/charmaps/ISO-8859-1 -i 
> /amd/devco/sebor/stdcxx/etc/nls/src/br_FR 
> /tmp/locale.11871/stage.1/br_FR.ISO-8859-1 >/dev/tty 2>&1
> LC_ALL=/tmp/locale.11871/stage.1/br_FR.ISO-8859-1 ./locale --charmap -l 
> >/tmp/locale.11871/stage.1/charmaps/ISO-8859-1 2>/dev/tty
> LC_ALL=/tmp/locale.11871/stage.1/br_FR.ISO-8859-1 ./locale -ck -h -l LC_ALL 
> >/tmp/locale.11871/stage.1/br_FR.src 2>/dev/tty
> mkdir -p /tmp/locale.11871/stage.2/charmaps
> ./localedef -w -c -f /tmp/locale.11871/stage.1/charmaps/ISO-8859-1 -i 
> /tmp/locale.11871/stage.1/br_FR.src 
> /tmp/locale.11871/stage.2/br_FR.ISO-8859-1 >/dev/tty 2>&1
> RWSTD_SRC_ROOT=/tmp/locale.11871/stage.1
> export RWSTD_SRC_ROOT
> LC_ALL=/tmp/locale.11871/stage.2/br_FR.ISO-8859-1 ./locale --charmap -l 
> >/tmp/locale.11871/stage.2/charmaps/ISO-8859-1 2>/dev/tty
> LC_ALL=/tmp/locale.11871/stage.2/br_FR.ISO-8859-1 ./locale -ck -h -l LC_ALL 
> >/tmp/locale.11871/stage.2/br_FR.src 2>/dev/tty
> mkdir -p /tmp/locale.11871/stage.3/charmaps
> ./localedef -w -c -f /tmp/locale.11871/stage.2/charmaps/ISO-8859-1 -i 
> /tmp/locale.11871/stage.2/br_FR.src 
> /tmp/locale.11871/stage.3/br_FR.ISO-8859-1 >/dev/tty 2>&1
> RWSTD_SRC_ROOT=/tmp/locale.11871/stage.2
> export RWSTD_SRC_ROOT
> LC_ALL=/tmp/locale.11871/stage.3/br_FR.ISO-8859-1 ./locale --charmap -l 
> >/tmp/locale.11871/stage.3/charmaps/ISO-8859-1 2>/dev/tty
> LC_ALL=/tmp/locale.11871/stage.3/br_FR.ISO-8859-1 ./locale -ck -h -l LC_ALL 
> >/tmp/locale.11871/stage.3/br_FR.src 2>/dev/tty
> diff /tmp/locale.11871/stage.1/charmaps/ISO-8859-1  
> /tmp/locale.11871/stage.2/charmaps/ISO-8859-1 >/dev/null
> diff /tmp/locale.11871/stage.2/charmaps/ISO-8859-1  
> /tmp/locale.11871/stage.3/charmaps/ISO-8859-1 >/dev/null
> diff /tmp/locale.11871/stage.2/br_FR.src  /tmp/locale.11871/stage.3/br_FR.src 
> >/dev/null
> ## AssertionFailed: /tmp/locale.11871/stage.2/br_FR.src  and 
> /tmp/locale.11871/stage.3/br_FR.src differ.
> # +---++++
> # | DIAGNOSTIC| ACTIVE |  TOTAL |INACTIVE|
> # +---++++
> # | (S7) ASSERTION|  1 | 16 |93% |
> # +---++++
> ## Assertions = 16
> ## FailedAssertions = 1
> $ diff /tmp/locale.11871/stage.2/br_FR.src /tmp/locale.11871/stage.3/br_FR.src
> 5,6c5,6
> < #   codeset_off: 8640
> < #   charmap_off: 8651
> ---
> > #   codeset_off: 8520
> > #   charmap_off: 8531
> 8c8
> < #   num_elms: 264
> ---
> > #   num_elms: 258
> 12,14c12
> < #   largest_ce: 2
> < collating-element  from ""
> < collating-element  from ""
> ---
> > #   largest_ce: 1
> 17,18d14
> <   \x38;\x23;\x0c;IGNORE;
> <   \x38;\x23;\x0d;IGNORE;

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

[jira] Updated: (STDCXX-233) std::strstreambuf::seekpos() fails to properly position get sequence

[Martin Sebor (JIRA)]

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

Martin Sebor updated STDCXX-233:


Affects Version/s: (was: 4.2)

This never did affect 4.2.

> std::strstreambuf::seekpos() fails to properly position get sequence
> 
>
> Key: STDCXX-233
> URL: https://issues.apache.org/jira/browse/STDCXX-233
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 27. Input/Output
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>
> Moved from the Rogue Wave bug tracking database:
> Created By: sebor @ Jul 01, 2000 08:28:15 PM
> This program fails with exit status of 1. It exits successfully (with 0) when 
> std::strstreambuf is replaced with std::stringbuf. I don't see anything in 
> D.7.1 that would require this behavior. Looks like a bug...
> The (enhanced) regress/test_bug10430.cpp exercises this bug and fails as a 
> result.
> #include 
> int main ()
> {
> std::strstreambuf sb;
> sb.sputn ("a", 1);
> sb.pubseekpos (0);
> char buf[2] = { 'X', 'Y' };
> return !(   1 == sb.sgetn (buf, sizeof buf)
>  && 'a' == buf [0] && 'Y' == buf [1]);
> }
> Modified By: sebor @ Nov 28, 2000 10:09:20 PM
> $ cat test_bug10430.out
> ## ---
> ## TestTag = RWQETest test_bug10430
> ## CompilerId  = g++-2.95.2
> ## MachineId   = SunOS killer 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-4
> ## Remark  = 
> ## RunTag  = test_bug10430 regression test
> ## FunctionTag = Issue #10430 -- streambufs delete passed in buffers.
> ##StepTag = stringbuf
> ##StepTag = filebuf
> ##StepTag = wstringstream
> ##StepTag = wfilebuf
> ##StepTag = strstreambuf
> ## -   AssertionTag = strstreambuf::sgetn ("", 11) == 11 (got 11)
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 102
> ## -   AssertionTag = strstreambuf::sgetn ("", 11); expected "0123456789"
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 107
> ## -   AssertionTag = strstreambuf::setbuf (0, 0) must have no effect
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 113
> ## -   AssertionTag = strstreambuf::sgetn ("", 11) == 11 (got 0)
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 121
> ## -   AssertionTag = strstreambuf::sgetn ("", 11); expected "0123456789"
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 126
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 1) must fail
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 133
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 1) must succeed
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 142
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 12) must succeed
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 151
> ## -   AssertionTag = strstreambuf<>::setbuf (63720, 22) must succeed
> ## -   FileName = 
> /build2/sebor/dev/stdlib/tests/regress/test_bug10430.cpp
> ## -   LineNumber   = 160
> ## Assertions = 75
> ## FailedAssertions = 9

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

[jira] Closed: (STDCXX-373) [locale] error: incomplete multibyte character on yi_US.CP1255

[Martin Sebor (JIRA)]

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

Martin Sebor closed STDCXX-373.
---

Resolution: Cannot Reproduce

Cannot reproduce the originally reported problem, but see STDCXX-540 for the 
new one.

> [locale] error: incomplete multibyte character on yi_US.CP1255
> --
>
> Key: STDCXX-373
> URL: https://issues.apache.org/jira/browse/STDCXX-373
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Locales
>Affects Versions: trunk
> Environment: gcc 3.4.6, Linux x86_64
>Reporter: Martin Sebor
>
> $ ./yi_US.CP1255 -d -n
> -bash: ./yi_US.CP1255: No such file or directory
> bin$ ./yi_US.CP1255.sh -d -n
> RWSTD_SRC_ROOT=/amd/devco/sebor/stdcxx/etc/nls
> export RWSTD_SRC_ROOT
> mkdir -p /tmp/locale.12106/stage.1/charmaps
> ./localedef -w -c -f /amd/devco/sebor/stdcxx/etc/nls/charmaps/CP1255 -i 
> /amd/devco/sebor/stdcxx/etc/nls/src/yi_US 
> /tmp/locale.12106/stage.1/yi_US.CP1255 >/dev/tty 2>&1
> LC_ALL=/tmp/locale.12106/stage.1/yi_US.CP1255 ./locale --charmap -l 
> >/tmp/locale.12106/stage.1/charmaps/CP1255 2>/dev/tty
> LC_ALL=/tmp/locale.12106/stage.1/yi_US.CP1255 ./locale -ck -h -l LC_ALL 
> >/tmp/locale.12106/stage.1/yi_US.src 2>/dev/tty
> Error 308: incomplete multibyte character in character map file: expecting 3 
> bytes, found 0

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

[jira] Updated: (STDCXX-373) [locale] error: incomplete multibyte character on yi_US.CP1255

[Martin Sebor (JIRA)]

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

Martin Sebor updated STDCXX-373:


Affects Version/s: (was: 4.2)
   trunk

Changed Affects Version/s to "trunk."

> [locale] error: incomplete multibyte character on yi_US.CP1255
> --
>
> Key: STDCXX-373
> URL: https://issues.apache.org/jira/browse/STDCXX-373
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Locales
>Affects Versions: trunk
> Environment: gcc 3.4.6, Linux x86_64
>Reporter: Martin Sebor
>
> $ ./yi_US.CP1255 -d -n
> -bash: ./yi_US.CP1255: No such file or directory
> bin$ ./yi_US.CP1255.sh -d -n
> RWSTD_SRC_ROOT=/amd/devco/sebor/stdcxx/etc/nls
> export RWSTD_SRC_ROOT
> mkdir -p /tmp/locale.12106/stage.1/charmaps
> ./localedef -w -c -f /amd/devco/sebor/stdcxx/etc/nls/charmaps/CP1255 -i 
> /amd/devco/sebor/stdcxx/etc/nls/src/yi_US 
> /tmp/locale.12106/stage.1/yi_US.CP1255 >/dev/tty 2>&1
> LC_ALL=/tmp/locale.12106/stage.1/yi_US.CP1255 ./locale --charmap -l 
> >/tmp/locale.12106/stage.1/charmaps/CP1255 2>/dev/tty
> LC_ALL=/tmp/locale.12106/stage.1/yi_US.CP1255 ./locale -ck -h -l LC_ALL 
> >/tmp/locale.12106/stage.1/yi_US.src 2>/dev/tty
> Error 308: incomplete multibyte character in character map file: expecting 3 
> bytes, found 0

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

[jira] Created: (STDCXX-540) [localedef] illegal multibyte prefix '\x90' in character map file on CP1255

[Martin Sebor (JIRA)]

[localedef] illegal multibyte prefix '\x90' in character map file on CP1255
---

 Key: STDCXX-540
 URL: https://issues.apache.org/jira/browse/STDCXX-540
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Utilities
Affects Versions: 4.1.3
Reporter: Martin Sebor
Priority: Minor
 Fix For: 4.2


The localedef utility has trouble processing the CP1255 character set 
description file:

$ (export RWSTD_SRC_ROOT=/nfs/devco/sebor/stdcxx/etc/nls; \
mkdir -p /tmp/$$ \
&& ./localedef -w -c -f $RWSTD_SRC_ROOT/charmaps/CP1255 -i 
$RWSTD_SRC_ROOT/src/yi_US /tmp/$$/yi_US.CP1255)
Error 308: illegal multibyte prefix '\x90' in character map file


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

[jira] Commented: (STDCXX-373) [locale] error: incomplete multibyte character on yi_US.CP1255

[Martin Sebor (JIRA)]

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

Martin Sebor commented on STDCXX-373:
-

This new problem must be a bug in the utility. There is no \x90 in the charmap, 
nor is there any such code in Code Page 1255: 
http://www.microsoft.com/globaldev/reference/sbcs/1255.mspx

> [locale] error: incomplete multibyte character on yi_US.CP1255
> --
>
> Key: STDCXX-373
> URL: https://issues.apache.org/jira/browse/STDCXX-373
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Locales
>Affects Versions: 4.2
> Environment: gcc 3.4.6, Linux x86_64
>Reporter: Martin Sebor
>
> $ ./yi_US.CP1255 -d -n
> -bash: ./yi_US.CP1255: No such file or directory
> bin$ ./yi_US.CP1255.sh -d -n
> RWSTD_SRC_ROOT=/amd/devco/sebor/stdcxx/etc/nls
> export RWSTD_SRC_ROOT
> mkdir -p /tmp/locale.12106/stage.1/charmaps
> ./localedef -w -c -f /amd/devco/sebor/stdcxx/etc/nls/charmaps/CP1255 -i 
> /amd/devco/sebor/stdcxx/etc/nls/src/yi_US 
> /tmp/locale.12106/stage.1/yi_US.CP1255 >/dev/tty 2>&1
> LC_ALL=/tmp/locale.12106/stage.1/yi_US.CP1255 ./locale --charmap -l 
> >/tmp/locale.12106/stage.1/charmaps/CP1255 2>/dev/tty
> LC_ALL=/tmp/locale.12106/stage.1/yi_US.CP1255 ./locale -ck -h -l LC_ALL 
> >/tmp/locale.12106/stage.1/yi_US.src 2>/dev/tty
> Error 308: incomplete multibyte character in character map file: expecting 3 
> bytes, found 0

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

[jira] Commented: (STDCXX-373) [locale] error: incomplete multibyte character on yi_US.CP1255

[Martin Sebor (JIRA)]

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

Martin Sebor commented on STDCXX-373:
-

I'm having trouble reproducing this problem with the latest trunk. What I get 
instead is:

$ (export RWSTD_SRC_ROOT=/nfs/devco/sebor/stdcxx/etc/nls; mkdir -p /tmp/$$ && 
./localedef -w -c -f $RWSTD_SRC_ROOT/charmaps/CP1255 -i 
$RWSTD_SRC_ROOT/src/yi_US /tmp/$$/yi_US.CP1255)
Error 308: illegal multibyte prefix '\x90' in character map file

Looks like the localedef utility cannot process the CP1255 character set 
description file.

Same behavior in 4.1.3.

Oddly, though, there is no x90 in the charmap.

$ grep "x90" /nfs/devco/sebor/stdcxx/etc/nls/charmaps/CP1255 || echo not found
not found


> [locale] error: incomplete multibyte character on yi_US.CP1255
> --
>
> Key: STDCXX-373
> URL: https://issues.apache.org/jira/browse/STDCXX-373
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Locales
>Affects Versions: 4.2
> Environment: gcc 3.4.6, Linux x86_64
>Reporter: Martin Sebor
>
> $ ./yi_US.CP1255 -d -n
> -bash: ./yi_US.CP1255: No such file or directory
> bin$ ./yi_US.CP1255.sh -d -n
> RWSTD_SRC_ROOT=/amd/devco/sebor/stdcxx/etc/nls
> export RWSTD_SRC_ROOT
> mkdir -p /tmp/locale.12106/stage.1/charmaps
> ./localedef -w -c -f /amd/devco/sebor/stdcxx/etc/nls/charmaps/CP1255 -i 
> /amd/devco/sebor/stdcxx/etc/nls/src/yi_US 
> /tmp/locale.12106/stage.1/yi_US.CP1255 >/dev/tty 2>&1
> LC_ALL=/tmp/locale.12106/stage.1/yi_US.CP1255 ./locale --charmap -l 
> >/tmp/locale.12106/stage.1/charmaps/CP1255 2>/dev/tty
> LC_ALL=/tmp/locale.12106/stage.1/yi_US.CP1255 ./locale -ck -h -l LC_ALL 
> >/tmp/locale.12106/stage.1/yi_US.src 2>/dev/tty
> Error 308: incomplete multibyte character in character map file: expecting 3 
> bytes, found 0

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

Fwd: KDE, The Standard C++ Library, Boost and Apache

[Martin Sebor]

See: http://lists.kde.org/?l=kde-solaris&m=118799139409611&w=2

And also:
http://www.opensolaris.org/jive/thread.jspa?threadID=37994&tstart=0

[jira] Updated: (STDCXX-388) [gcc 3.4.4/FreeBSD 6.1/IA64] many errors for runtime symbols linking with stdcxx

[Martin Sebor (JIRA)]

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

Martin Sebor updated STDCXX-388:


Fix Version/s: 4.2.1

Scheduled for 4.2.1 on the assumption that we get access to the platform.

> [gcc 3.4.4/FreeBSD 6.1/IA64] many errors for runtime symbols linking with 
> stdcxx
> 
>
> Key: STDCXX-388
> URL: https://issues.apache.org/jira/browse/STDCXX-388
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 4.2
> Environment: gcc 3.4.4/FreeBSD 6.1/IA64
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>Priority: Minor
> Fix For: 4.2.1
>
>
> All examples (or other programs) fail to link on FreeBSD with errors like the 
> ones below:
> $ nice gmake accumulate
> gcc accumulate.o -o accumulate  
> -L/house/sebor/build/stdcxx-2007-03-30-r524321-freebsd-6.1-ia64-gcc-3.4.4-11s/lib
>   -lstd11s -lsupc++ -lm 
> /usr/lib/libsupc++.a(new_handler.o)(.text._ZNSt9bad_allocD1Ev+0x0): In 
> function `std::bad_alloc::~bad_alloc()':
> : multiple definition of `std::bad_alloc::~bad_alloc()'
> /house/sebor/build/stdcxx-2007-03-30-r524321-freebsd-6.1-ia64-gcc-3.4.4-11s/lib/libstd11s.a(memory.o)(.text+0x6d0):/house/sebor/stdcxx-2007-03-30-r524321/src/memory.cpp:301:
>  first defined here
> /usr/bin/ld: Warning: size of symbol `_ZNSt9bad_allocD1Ev' changed from 192 
> in /usr/lib/libsupc++.a(new_handler.o) to 96 in 
> /usr/lib/libsupc++.a(new_handler.o)
> /usr/lib/libsupc++.a(new_handler.o)(.text._ZNSt9bad_allocD0Ev+0x0): In 
> function `std::bad_alloc::~bad_alloc()':
> : multiple definition of `std::bad_alloc::~bad_alloc()'
> /house/sebor/build/stdcxx-2007-03-30-r524321-freebsd-6.1-ia64-gcc-3.4.4-11s/lib/libstd11s.a(memory.o)(.text+0x790):/house/sebor/stdcxx-2007-03-30-r524321/src/memory.cpp:301:
>  first defined here
> /usr/bin/ld: Warning: size of symbol `_ZNSt9bad_allocD0Ev' changed from 192 
> in /usr/lib/libsupc++.a(new_handler.o) to 112 in 
> /usr/lib/libsupc++.a(new_handler.o)
> /usr/lib/libsupc++.a(new_handler.o)(.text._ZNSt9bad_allocD2Ev+0x0): In 
> function `std::bad_alloc::~bad_alloc()':
> : multiple definition of `std::bad_alloc::~bad_alloc()'
> /house/sebor/build/stdcxx-2007-03-30-r524321-freebsd-6.1-ia64-gcc-3.4.4-11s/lib/libstd11s.a(memory.o)(.text+0x610):/house/sebor/stdcxx-2007-03-30-r524321/src/memory.cpp:301:
>  first defined here
> /usr/bin/ld: Warning: size of symbol `_ZNSt9bad_allocD2Ev' changed from 192 
> in /usr/lib/libsupc++.a(new_handler.o) to 96 in 
> /usr/lib/libsupc++.a(new_handler.o)
> /usr/lib/libsupc++.a(eh_exception.o)(.text._ZNSt9exceptionD1Ev+0x0): In 
> function `std::exception::~exception()':
> : multiple definition of `std::exception::~exception()'
> /house/sebor/build/stdcxx-2007-03-30-r524321-freebsd-6.1-ia64-gcc-3.4.4-11s/lib/libstd11s.a(exception.o)(.text+0x210):/house/sebor/stdcxx-2007-03-30-r524321/src/exception.cpp:323:
>  first defined here
> /usr/bin/ld: Warning: size of symbol `_ZNSt9exceptionD1Ev' changed from 176 
> in /usr/lib/libsupc++.a(eh_exception.o) to 48 in 
> /usr/lib/libsupc++.a(eh_exception.o)
> /usr/lib/libsupc++.a(eh_exception.o)(.text._ZNSt9exceptionD0Ev+0x0): In 
> function `std::exception::~exception()':
> : multiple definition of `std::exception::~exception()'
> /house/sebor/build/stdcxx-2007-03-30-r524321-freebsd-6.1-ia64-gcc-3.4.4-11s/lib/libstd11s.a(exception.o)(.text+0x2c0):/house/sebor/stdcxx-2007-03-30-r524321/src/exception.cpp:323:
>  first defined here
> /usr/bin/ld: Warning: size of symbol `_ZNSt9exceptionD0Ev' changed from 176 
> in /usr/lib/libsupc++.a(eh_exception.o) to 96 in 
> /usr/lib/libsupc++.a(eh_exception.o)
> /usr/lib/libsupc++.a(eh_exception.o)(.text._ZNSt13bad_exceptionD1Ev+0x0): In 
> function `std::bad_exception::~bad_exception()':
> : multiple definition of `std::bad_exception::~bad_exception()'
> /house/sebor/build/stdcxx-2007-03-30-r524321-freebsd-6.1-ia64-gcc-3.4.4-11s/lib/libstd11s.a(exception.o)(.text+0x6c0):/house/sebor/stdcxx-2007-03-30-r524321/src/exception.cpp:391:
>  first defined here
> /usr/bin/ld: Warning: size of symbol `_ZNSt13bad_exceptionD1Ev' changed from 
> 192 in /usr/lib/libsupc++.a(eh_exception.o) to 96 in 
> /usr/lib/libsupc++.a(eh_exception.o)
> /usr/lib/libsupc++.a(eh_exception.o)(.text._ZNSt13bad_exceptionD0Ev+0x0): In 
> function `std::bad_exception::~bad_exception()':
> : multiple definition of `std::bad_exception::~bad_exception()'
> /house/sebor/build/stdcxx-2007-03-30-r524321-freebsd-6.1-ia64-gcc-3.4.4-11s/lib/libstd11s.a(exception.o)(.text+0x780):/house/sebor/stdcxx-2007-03-30-r524321/src/exception.cpp:391:
>  first defined here
> /usr/bin/ld: Warning: size of symbol `_ZNSt13bad_exceptionD0Ev' changed from 
> 192 in /usr/lib/libsupc++.a(eh_exception.o) to 112 in 
> /usr/lib

[jira] Closed: (STDCXX-390) [HP aCC 3.73] error on std::uninitialized_copy()

[Martin Sebor (JIRA)]

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

Martin Sebor closed STDCXX-390.
---

Resolution: Fixed

Fixed by the referenced patch. Regression test committed thus: 
http://svn.apache.org/viewvc?rev=570590&view=rev

> [HP aCC 3.73] error on std::uninitialized_copy()
> 
>
> Key: STDCXX-390
> URL: https://issues.apache.org/jira/browse/STDCXX-390
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 20. General Utilities
>Affects Versions: 4.1.3, 4.1.4
> Environment: HP aCC 3.73 and prior
>Reporter: Martin Sebor
>Assignee: Martin Sebor
> Fix For: 4.2
>
>
> The program below fails to compile with HP aCC 3.73. It compiles successfully 
> with other compilers (including the EDG eccp-based aCC 3.76 beta)
> $ cat t.cpp && nice gmake _CXXOPTS=-V t
> #include 
> int main ()
> {
> int i = 0;
> const int ci = 0;
> volatile int vi = 0;
> const volatile int cvi = 0;
> std::uninitialized_copy (&i, &i, &i);
> std::uninitialized_copy (&i, &i, &vi);
> std::uninitialized_copy (&ci, &ci, &i);
> std::uninitialized_copy (&ci, &ci, &vi);
> std::uninitialized_copy (&vi, &vi, &i);
> std::uninitialized_copy (&vi, &vi, &vi);
> std::uninitialized_copy (&cvi, &cvi, &i);
> std::uninitialized_copy (&cvi, &cvi, &vi);
> }
> cadvise aCC -c -I/amd/devco/sebor/stdcxx/include/ansi -I/usr/include-mt 
> -I/amd/devco/sebor/stdcxx/include -I/build/sebor/stdcxx-aCC-3.73-12D/include 
> -I/amd/devco/sebor/stdcxx/tests/include  -Aa +nostl -V +O2 +Oinitcheck +DD64 
> +w +W392 +W655 +W684 +W818 +W819 +W849   t.cpp
> aCC: HP ANSI C++ B3910B A.03.73
> Error 226: "/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 164 # No 
> appropriate function
> found for call of '__rw_construct'. Last viable candidate was "void
> __rw::__rw_construct(int *,const int &)"
> ["/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 84]. Argument 
> of type 'volatile
> int' could not be converted to 'const int &'.
> _RW::__rw_construct (&*__res, *__first);
> ^^^ 
> Error 556: "t.cpp", line 16 # Unable to generate specialization "int
> *std::uninitialized_copy(volatile int *,volatile 
> int *,int *)" due to
> errors during generation.
> std::uninitialized_copy (&vi, &vi, &i);
> ^^ 
> Error 556: "t.cpp", line 16 # Unable to generate specialization "int
> *std::uninitialized_copy(volatile int *,volatile 
> int *,int *)" due to
> errors during generation.
> std::uninitialized_copy (&vi, &vi, &i);
> ^^ 
> Error 226: "/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 164 # No 
> appropriate function
> found for call of '__rw_construct'. Last viable candidate was "void
> __rw::__rw_construct(volatile int *,const int &)"
> ["/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 92]. Argument 
> of type 'volatile
> int' could not be converted to 'const int &'.
> _RW::__rw_construct (&*__res, *__first);
> ^^^ 
> Error 556: "t.cpp", line 17 # Unable to generate specialization "volatile int
> *std::uninitialized_copy(volatile int 
> *,volatile int *,volatile
> int *)" due to errors during generation.
> std::uninitialized_copy (&vi, &vi, &vi);
> ^^^ 
> Error 556: "t.cpp", line 17 # Unable to generate specialization "volatile int
> *std::uninitialized_copy(volatile int 
> *,volatile int *,volatile
> int *)" due to errors during generation.
> std::uninitialized_copy (&vi, &vi, &vi);
> ^^^ 
> Error 226: "/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 164 # No 
> appropriate function
> found for call of '__rw_construct'. Last viable candidate was "void
> __rw::__rw_construct(int *,const int &)"
> ["/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 84]. Argument 
> of type 'const
> volatile int' could not be converted to 'const int &'.
> _RW::__rw_construct (&*__res, *__first);
> ^^^ 
> Error 556: "t.cpp", line 19 # Unable to generate specialization "int
> *std::uninitialized_copy(const volatile int 
> *,const volatile int
> *,int *)" due to errors during generation.
> std::uninitialized_copy (&cvi, &cvi, &i);
>  
> Error 556: "t.cpp", line 19 # Unable to generate specialization "int
> *std::uninitialized_copy(const volatile int 
> *,const volatile int
> *

[jira] Updated: (STDCXX-390) [HP aCC 3.73] error on std::uninitialized_copy()

[Martin Sebor (JIRA)]

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

Martin Sebor updated STDCXX-390:


Affects Version/s: (was: 4.2)
   4.1.3
   4.1.4
Fix Version/s: 4.2

Set Affects Version/s to 4.1.3 and 4.1.4 and Fix Version/s to 4.2.

> [HP aCC 3.73] error on std::uninitialized_copy()
> 
>
> Key: STDCXX-390
> URL: https://issues.apache.org/jira/browse/STDCXX-390
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 20. General Utilities
>Affects Versions: 4.1.3, 4.1.4
> Environment: HP aCC 3.73 and prior
>Reporter: Martin Sebor
>Assignee: Martin Sebor
> Fix For: 4.2
>
>
> The program below fails to compile with HP aCC 3.73. It compiles successfully 
> with other compilers (including the EDG eccp-based aCC 3.76 beta)
> $ cat t.cpp && nice gmake _CXXOPTS=-V t
> #include 
> int main ()
> {
> int i = 0;
> const int ci = 0;
> volatile int vi = 0;
> const volatile int cvi = 0;
> std::uninitialized_copy (&i, &i, &i);
> std::uninitialized_copy (&i, &i, &vi);
> std::uninitialized_copy (&ci, &ci, &i);
> std::uninitialized_copy (&ci, &ci, &vi);
> std::uninitialized_copy (&vi, &vi, &i);
> std::uninitialized_copy (&vi, &vi, &vi);
> std::uninitialized_copy (&cvi, &cvi, &i);
> std::uninitialized_copy (&cvi, &cvi, &vi);
> }
> cadvise aCC -c -I/amd/devco/sebor/stdcxx/include/ansi -I/usr/include-mt 
> -I/amd/devco/sebor/stdcxx/include -I/build/sebor/stdcxx-aCC-3.73-12D/include 
> -I/amd/devco/sebor/stdcxx/tests/include  -Aa +nostl -V +O2 +Oinitcheck +DD64 
> +w +W392 +W655 +W684 +W818 +W819 +W849   t.cpp
> aCC: HP ANSI C++ B3910B A.03.73
> Error 226: "/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 164 # No 
> appropriate function
> found for call of '__rw_construct'. Last viable candidate was "void
> __rw::__rw_construct(int *,const int &)"
> ["/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 84]. Argument 
> of type 'volatile
> int' could not be converted to 'const int &'.
> _RW::__rw_construct (&*__res, *__first);
> ^^^ 
> Error 556: "t.cpp", line 16 # Unable to generate specialization "int
> *std::uninitialized_copy(volatile int *,volatile 
> int *,int *)" due to
> errors during generation.
> std::uninitialized_copy (&vi, &vi, &i);
> ^^ 
> Error 556: "t.cpp", line 16 # Unable to generate specialization "int
> *std::uninitialized_copy(volatile int *,volatile 
> int *,int *)" due to
> errors during generation.
> std::uninitialized_copy (&vi, &vi, &i);
> ^^ 
> Error 226: "/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 164 # No 
> appropriate function
> found for call of '__rw_construct'. Last viable candidate was "void
> __rw::__rw_construct(volatile int *,const int &)"
> ["/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 92]. Argument 
> of type 'volatile
> int' could not be converted to 'const int &'.
> _RW::__rw_construct (&*__res, *__first);
> ^^^ 
> Error 556: "t.cpp", line 17 # Unable to generate specialization "volatile int
> *std::uninitialized_copy(volatile int 
> *,volatile int *,volatile
> int *)" due to errors during generation.
> std::uninitialized_copy (&vi, &vi, &vi);
> ^^^ 
> Error 556: "t.cpp", line 17 # Unable to generate specialization "volatile int
> *std::uninitialized_copy(volatile int 
> *,volatile int *,volatile
> int *)" due to errors during generation.
> std::uninitialized_copy (&vi, &vi, &vi);
> ^^^ 
> Error 226: "/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 164 # No 
> appropriate function
> found for call of '__rw_construct'. Last viable candidate was "void
> __rw::__rw_construct(int *,const int &)"
> ["/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 84]. Argument 
> of type 'const
> volatile int' could not be converted to 'const int &'.
> _RW::__rw_construct (&*__res, *__first);
> ^^^ 
> Error 556: "t.cpp", line 19 # Unable to generate specialization "int
> *std::uninitialized_copy(const volatile int 
> *,const volatile int
> *,int *)" due to errors during generation.
> std::uninitialized_copy (&cvi, &cvi, &i);
>  
> Error 556: "t.cpp", line 19 # Unable to generate specialization "int
> *std::uninitialize

[jira] Assigned: (STDCXX-390) [HP aCC 3.73] error on std::uninitialized_copy()

[Martin Sebor (JIRA)]

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

Martin Sebor reassigned STDCXX-390:
---

Assignee: Martin Sebor

> [HP aCC 3.73] error on std::uninitialized_copy()
> 
>
> Key: STDCXX-390
> URL: https://issues.apache.org/jira/browse/STDCXX-390
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 20. General Utilities
>Affects Versions: 4.2
> Environment: HP aCC 3.73 and prior
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>
> The program below fails to compile with HP aCC 3.73. It compiles successfully 
> with other compilers (including the EDG eccp-based aCC 3.76 beta)
> $ cat t.cpp && nice gmake _CXXOPTS=-V t
> #include 
> int main ()
> {
> int i = 0;
> const int ci = 0;
> volatile int vi = 0;
> const volatile int cvi = 0;
> std::uninitialized_copy (&i, &i, &i);
> std::uninitialized_copy (&i, &i, &vi);
> std::uninitialized_copy (&ci, &ci, &i);
> std::uninitialized_copy (&ci, &ci, &vi);
> std::uninitialized_copy (&vi, &vi, &i);
> std::uninitialized_copy (&vi, &vi, &vi);
> std::uninitialized_copy (&cvi, &cvi, &i);
> std::uninitialized_copy (&cvi, &cvi, &vi);
> }
> cadvise aCC -c -I/amd/devco/sebor/stdcxx/include/ansi -I/usr/include-mt 
> -I/amd/devco/sebor/stdcxx/include -I/build/sebor/stdcxx-aCC-3.73-12D/include 
> -I/amd/devco/sebor/stdcxx/tests/include  -Aa +nostl -V +O2 +Oinitcheck +DD64 
> +w +W392 +W655 +W684 +W818 +W819 +W849   t.cpp
> aCC: HP ANSI C++ B3910B A.03.73
> Error 226: "/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 164 # No 
> appropriate function
> found for call of '__rw_construct'. Last viable candidate was "void
> __rw::__rw_construct(int *,const int &)"
> ["/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 84]. Argument 
> of type 'volatile
> int' could not be converted to 'const int &'.
> _RW::__rw_construct (&*__res, *__first);
> ^^^ 
> Error 556: "t.cpp", line 16 # Unable to generate specialization "int
> *std::uninitialized_copy(volatile int *,volatile 
> int *,int *)" due to
> errors during generation.
> std::uninitialized_copy (&vi, &vi, &i);
> ^^ 
> Error 556: "t.cpp", line 16 # Unable to generate specialization "int
> *std::uninitialized_copy(volatile int *,volatile 
> int *,int *)" due to
> errors during generation.
> std::uninitialized_copy (&vi, &vi, &i);
> ^^ 
> Error 226: "/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 164 # No 
> appropriate function
> found for call of '__rw_construct'. Last viable candidate was "void
> __rw::__rw_construct(volatile int *,const int &)"
> ["/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 92]. Argument 
> of type 'volatile
> int' could not be converted to 'const int &'.
> _RW::__rw_construct (&*__res, *__first);
> ^^^ 
> Error 556: "t.cpp", line 17 # Unable to generate specialization "volatile int
> *std::uninitialized_copy(volatile int 
> *,volatile int *,volatile
> int *)" due to errors during generation.
> std::uninitialized_copy (&vi, &vi, &vi);
> ^^^ 
> Error 556: "t.cpp", line 17 # Unable to generate specialization "volatile int
> *std::uninitialized_copy(volatile int 
> *,volatile int *,volatile
> int *)" due to errors during generation.
> std::uninitialized_copy (&vi, &vi, &vi);
> ^^^ 
> Error 226: "/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 164 # No 
> appropriate function
> found for call of '__rw_construct'. Last viable candidate was "void
> __rw::__rw_construct(int *,const int &)"
> ["/amd/devco/sebor/stdcxx/include/rw/_specialized.h", line 84]. Argument 
> of type 'const
> volatile int' could not be converted to 'const int &'.
> _RW::__rw_construct (&*__res, *__first);
> ^^^ 
> Error 556: "t.cpp", line 19 # Unable to generate specialization "int
> *std::uninitialized_copy(const volatile int 
> *,const volatile int
> *,int *)" due to errors during generation.
> std::uninitialized_copy (&cvi, &cvi, &i);
>  
> Error 556: "t.cpp", line 19 # Unable to generate specialization "int
> *std::uninitialized_copy(const volatile int 
> *,const volatile int
> *,int *)" due to errors during generation.
> std::uninitialized_copy (&cvi, &cvi, &i);
> ^^^

[jira] Updated: (STDCXX-424) [gcc 3.3.3] warning: inlining failed in call to std::valarray copy ctor

[Martin Sebor (JIRA)]

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

Martin Sebor updated STDCXX-424:


Affects Version/s: (was: 4.2)
   4.1.4
Fix Version/s: 4.2

Replaced 4.2 in Affected Versions with 4.1.3 and 4.1.4 since 4.2 hasn't been 
released yet and scheduled for 4.2.

> [gcc 3.3.3] warning: inlining failed in call to std::valarray copy ctor
> ---
>
> Key: STDCXX-424
> URL: https://issues.apache.org/jira/browse/STDCXX-424
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 26. Numerics
>Affects Versions: 4.1.3, 4.1.4
> Environment: gcc 3.3.3 on Linux
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>Priority: Minor
> Fix For: 4.2
>
>
> We're getting lots of warnings like the ones below from valarray tests. Even 
> four levels of inlining in user code (not at all uncommon) triggers the 
> noise...
> $ cat t.cpp && make t
> #include 
> inline void f0 (std::valarray) { }
> inline void f1 (std::valarray va) { f0 (va); }
> inline void f2 (std::valarray va) { f1 (va); }
> inline void f3 (std::valarray va) { f2 (va); }
> inline void f4 (std::valarray va) { f3 (va); }
> int main ()
> {
> f4 (std::valarray());
> }
> gcc -c -I/amd/devco/sebor/stdcxx/include/ansi   -pthread 
> -I/amd/devco/sebor/stdcxx/include 
> -I/build/sebor/stdcxx-gcc-3.3.3_43.41-12d/include 
> -I/amd/devco/sebor/stdcxx/examples/include  -pedantic -nostdinc++ -O2  -m32 
> -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long 
> -Wcast-align   t.cpp
> gcc t.o -o t -pthread -m32 -L/build/sebor/stdcxx-gcc-3.3.3_43.41-12d/lib  
> -Wl,-R/build/sebor/stdcxx-gcc-3.3.3_43.41-12d/lib -lstd12d -lsupc++ -lm 
> In file included from /amd/devco/sebor/stdcxx/include/rw/_array.h:7:
> t.cpp: In function `int main()':
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call 
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with 
>_TypeT = int]'
> t.cpp:6: warning: called from here
> In file included from /amd/devco/sebor/stdcxx/include/rw/_array.h:6:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call 
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with 
>_TypeT = int]'
> t.cpp:5: warning: called from here
> In file included from /amd/devco/sebor/stdcxx/include/rw/_array.h:5:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call 
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with 
>_TypeT = int]'
> t.cpp:4: warning: called from here
> In file included from /amd/devco/sebor/stdcxx/include/rw/_array.h:4:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call 
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with 
>_TypeT = int]'
> t.cpp:3: warning: called from here
> In file included from t.cpp:7,
>  from t.cpp:11:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call 
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with 
>_TypeT = int]'
> t.cpp:6: warning: called from here
> In file included from t.cpp:6,
>  from t.cpp:7,
>  from t.cpp:11:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call 
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with 
>_TypeT = int]'
> t.cpp:5: warning: called from here
> In file included from t.cpp:5,
>  from t.cpp:6,
>  from t.cpp:7,
>  from t.cpp:11:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call 
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with 
>_TypeT = int]'
> t.cpp:4: warning: called from here
> In file included from t.cpp:4,
>  from t.cpp:5,
>  from t.cpp:6,
>  from t.cpp:7,
>  from t.cpp:11:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call 
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with 
>_TypeT = int]'
> t.cpp:3: warning: called from here

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

[jira] Updated: (STDCXX-436) [Linux] MB_LEN_MAX incorrect

[Martin Sebor (JIRA)]

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

Martin Sebor updated STDCXX-436:


Affects Version/s: (was: 4.2)
   4.1.3

Also confirmed with 4.1.3 so it's not a regression. The problem doesn't exist 
on HP-UX or Solaris.

> [Linux] MB_LEN_MAX incorrect
> 
>
> Key: STDCXX-436
> URL: https://issues.apache.org/jira/browse/STDCXX-436
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 18. Language Support
>Affects Versions: 4.1.3
> Environment: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
>Reporter: Mark Brown
>Assignee: Martin Sebor
>
> On my Linux system MB_LEN_MAX is normally defined to 16 but when I use the 
> macro in a program compiled with stdcxx the macro evaluates to 1. The test 
> case goes like this:
> $ cat test.cpp && make CPPOPTS="-DGETCONF_MB_LEN_MAX=`getconf MB_LEN_MAX`" 
> test && ./test
> #include 
> #include 
> int main ()
> {
> assert (MB_LEN_MAX == GETCONF_MB_LEN_MAX);
> }
> gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG
> -I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-gcc-4.1.1-11s/include 
> -I/home/mbrown/stdcxx/examples/include -DGETCONF_MB_LEN_MAX=16 -pedantic 
> -nostdinc++ -g  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
> -Wno-long-long -Wcast-align   test.cpp
> gcc u.o -o u  -L/home/mbrown/stdcxx-gcc-4.1.1-11s/lib  -lstd11s -lsupc++ -lm 
> test: test.cpp:6: int main(): Assertion `1 == 16' failed.
> Aborted

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

[jira] Assigned: (STDCXX-436) [Linux] MB_LEN_MAX incorrect

[Martin Sebor (JIRA)]

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

Martin Sebor reassigned STDCXX-436:
---

Assignee: Martin Sebor

> [Linux] MB_LEN_MAX incorrect
> 
>
> Key: STDCXX-436
> URL: https://issues.apache.org/jira/browse/STDCXX-436
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 18. Language Support
>Affects Versions: 4.2
> Environment: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
>Reporter: Mark Brown
>Assignee: Martin Sebor
>
> On my Linux system MB_LEN_MAX is normally defined to 16 but when I use the 
> macro in a program compiled with stdcxx the macro evaluates to 1. The test 
> case goes like this:
> $ cat test.cpp && make CPPOPTS="-DGETCONF_MB_LEN_MAX=`getconf MB_LEN_MAX`" 
> test && ./test
> #include 
> #include 
> int main ()
> {
> assert (MB_LEN_MAX == GETCONF_MB_LEN_MAX);
> }
> gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG
> -I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-gcc-4.1.1-11s/include 
> -I/home/mbrown/stdcxx/examples/include -DGETCONF_MB_LEN_MAX=16 -pedantic 
> -nostdinc++ -g  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
> -Wno-long-long -Wcast-align   test.cpp
> gcc u.o -o u  -L/home/mbrown/stdcxx-gcc-4.1.1-11s/lib  -lstd11s -lsupc++ -lm 
> test: test.cpp:6: int main(): Assertion `1 == 16' failed.
> Aborted

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

[jira] Commented: (STDCXX-436) [Linux] MB_LEN_MAX incorrect

[Martin Sebor (JIRA)]

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

Martin Sebor commented on STDCXX-436:
-

Confirmed on Red Hat EL 4.4:

$ cat /etc/redhat-release && icc --version && make 
CPPOPTS="-DGETCONF_MB_LEN_MAX=`getconf MB_LEN_MAX`" t && ./t
Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
icc (ICC) 10.0 20070613
Copyright (C) 1985-2007 Intel Corporation.  All rights reserved.

icc -c -I/amd/devco/sebor/stdcxx/include/ansi -D_RWSTDDEBUG   -D_REENTRANT 
-I/amd/devco/sebor/stdcxx/include 
-I/build/sebor/stdcxx-icc-10.0.025-15D/include 
-I/amd/devco/sebor/stdcxx/examples/include -DGETCONF_MB_LEN_MAX=16 
-cxxlib-nostd -g   -w1   t.cpp
icc t.o -o t -cxxlib-nostd  -lpthread  
-L/build/sebor/stdcxx-icc-10.0.025-15D/lib  
-Wl,-R/build/sebor/stdcxx-icc-10.0.025-15D/lib -lstd15D -lcxaguard -lsupc++ -lm 
t: t.cpp:6: int main(): Assertion `1 == 16' failed.
Aborted


> [Linux] MB_LEN_MAX incorrect
> 
>
> Key: STDCXX-436
> URL: https://issues.apache.org/jira/browse/STDCXX-436
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 18. Language Support
>Affects Versions: 4.2
> Environment: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
>Reporter: Mark Brown
>
> On my Linux system MB_LEN_MAX is normally defined to 16 but when I use the 
> macro in a program compiled with stdcxx the macro evaluates to 1. The test 
> case goes like this:
> $ cat test.cpp && make CPPOPTS="-DGETCONF_MB_LEN_MAX=`getconf MB_LEN_MAX`" 
> test && ./test
> #include 
> #include 
> int main ()
> {
> assert (MB_LEN_MAX == GETCONF_MB_LEN_MAX);
> }
> gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG
> -I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-gcc-4.1.1-11s/include 
> -I/home/mbrown/stdcxx/examples/include -DGETCONF_MB_LEN_MAX=16 -pedantic 
> -nostdinc++ -g  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
> -Wno-long-long -Wcast-align   test.cpp
> gcc u.o -o u  -L/home/mbrown/stdcxx-gcc-4.1.1-11s/lib  -lstd11s -lsupc++ -lm 
> test: test.cpp:6: int main(): Assertion `1 == 16' 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-489) [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect

[Martin Sebor (JIRA)]

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

Martin Sebor closed STDCXX-489.
---

Assignee: Andrew Black

Assigned to Andrew since he Resolved it (as Invalid) and Closed.

> [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect
> -
>
> Key: STDCXX-489
> URL: https://issues.apache.org/jira/browse/STDCXX-489
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: trunk
> Environment: Intel C++ 10 on Linux
>Reporter: Mark Brown
>Assignee: Andrew Black
>
> Configuring stdcxx for 32-bits using 
> BUILDMODE=pthreads,archive,optimized,narrow on x86_64 I see the system 
> architecture is "LP64 little endian" instead of "ILP32 little endian." It 
> looks like the "narrow" in BUILDMODE has no effect, kind of like "wide" had 
> no effect in bug STDCXX-470.
> $ nice make BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s 
> BUILDMODE=pthreads,archive,optimized,narrow CONFIG=icc.config
> creating BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s
> generating /home/mbrown/stdcxx-icc-10.0-12s/makefile.in from 
> /home/mbrown/stdcxx/etc/config/icc.config
> make[1]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s'
> make[2]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include'
> make config
> make[3]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include'
> configuring stdcxx 4.2.0 for icc-10.0 on linux-2.6.18-1.2798.fc6-x86_64
> checking if the compiler is sane   ok (invoked with icc)
> checking if the linker is sane ok (invoked with icc)
> checking system architecture   LP64 little endian

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

[jira] Updated: (STDCXX-489) [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect

[Martin Sebor (JIRA)]

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

Martin Sebor updated STDCXX-489:


Affects Version/s: (was: 4.2)
   trunk

Reported against trunk, not an actual release.

> [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect
> -
>
> Key: STDCXX-489
> URL: https://issues.apache.org/jira/browse/STDCXX-489
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: trunk
> Environment: Intel C++ 10 on Linux
>Reporter: Mark Brown
>
> Configuring stdcxx for 32-bits using 
> BUILDMODE=pthreads,archive,optimized,narrow on x86_64 I see the system 
> architecture is "LP64 little endian" instead of "ILP32 little endian." It 
> looks like the "narrow" in BUILDMODE has no effect, kind of like "wide" had 
> no effect in bug STDCXX-470.
> $ nice make BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s 
> BUILDMODE=pthreads,archive,optimized,narrow CONFIG=icc.config
> creating BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s
> generating /home/mbrown/stdcxx-icc-10.0-12s/makefile.in from 
> /home/mbrown/stdcxx/etc/config/icc.config
> make[1]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s'
> make[2]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include'
> make config
> make[3]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include'
> configuring stdcxx 4.2.0 for icc-10.0 on linux-2.6.18-1.2798.fc6-x86_64
> checking if the compiler is sane   ok (invoked with icc)
> checking if the linker is sane ok (invoked with icc)
> checking system architecture   LP64 little endian

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

Re: [RFC] draft stdcxx resolution for the Board

[Martin Sebor]

Mark Brown wrote:

Martin,

I am quite certain that "Apache ServiceMix" in the resolution should read "Apache 
C++ Standard Library."


Ah, yes, of course. A copy-and-paste typo.

Thanks for the careful proofreading!
Martin



   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Martin Sebor be
   appointed to the office of Vice President, Apache ServiceMix,
  ^

   to serve in accordance with and subject to the direction of
   the Board of Directors and the Bylaws of the Foundation until
   death, resignation, retirement, removal or disqualification,
   or until a successor is appointed; and be it further

-- Mark


-Original Message-
From: [EMAIL PROTECTED]
Sent: Mon, 27 Aug 2007 14:59:15 -0600
To: stdcxx-dev@incubator.apache.org
Subject: [RFC] draft stdcxx resolution for the Board

I'm working on the Board resolution based on the following page:

http://incubator.apache.org/guides/graduation.html#tlp-resolution

and I have a few issues I need help with. I'm hoping that our
mentors can give us guidance here, although I certainly encourage
everyone else, most of all committers, to read through this and
provide feedback.


1. Official project name: Apache C++ Standard Library

I have always assumed that the official name of our project is
the Apache C++ Standard Library, and that STDCXX is an "acronym"
or "keyword" (e.g., the same way APR is to the Apache Portable
Runtime Project). I'm not 100% sure that everyone shares the
same view so I'm looking for a confirmation that "Apache C++
Standard Library" is an acceptable name to use in the resolution.
(The attached proposed resolution assumes the answer is
affirmative.)


2. Composition of the initial PMC.

At the moment, our index page lists 11, and soon hopefully 13
committers, plus 3 mentors (see
http://incubator.apache.org/stdcxx/#committers):

   1. Andrew Black(PPMC member)
   2. Heidi Buelow(PPMC member, Emeritus)
   3. Lance Diduck
   4. John Hollis (Emeritus)
   5. Amit Jindal (PPMC member)
   6. Liviu Nicoara   (PPMC member)
   7. Ravi Palepu (Emeritus)
   8. Anton Pevtsov   (PPMC member)
   9. Martin Sebor(PPMC member)
  10. Tim Triemstra   (PPMC member)
  11. Farid Zaripov   (PPMC member)
  12. Mark Brown  (pending IPMC approval)
  13. Eric Lemings(pending IPMC approval)
  14. Ben Laurie  (Mentor)
  15. William Rowe, Jr.   (Mentor)
  16. Justin Erenkrantz   (Mentor)

First, I'm sure everyone agrees with me that Bill and Justin have
been a great help and that it would be a privilege to have both
of you on the PMC. The question is, busy as I'm sure you are, do
either of you wish not to be on it? (The attached proposed
resolution assumes the answer is no, i.e., both Bill and Justin
are on the PMC -- please speak up if that's not the case.)

Second, I assume that in general, the entire podling's PPMC
becomes the (proposed) PMC by default. The question I have about
our PPMC is: do PMC members who are in the status of Emeritus
fall into the same category? (The attached proposed resolution
assumes the answer is yes.)

Finally, the attached proposed resolution assumes that the IPMC
approves both Brad and Mark as the new committers. I intend to
wait to submit the proposal until the IMPC vote on their commit
access has closed. If anyone thinks we should not wait please
speak up.


3. Vice President (PMC Chair?)

The Board resolution must nominate a Vice President for top level
projects. First, is this the same thing as the PMC Chair (see the
definition below)? Second, we need to nominate someone for this
office. Unless someone would like to volunteer for this post or
unless we need to go through a formal vote process, I would be
happy to volunteer for the office. (The attached proposed
resolution has my name in that role.)

http://apache.org/foundation/how-it-works.html#pmc-chair

Thanks
Martin

Re: [PATCH] STDCXX-77

[Martin Sebor]

Farid Zaripov wrote:

-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Tuesday, August 28, 2007 7:11 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: [PATCH] STDCXX-77

I have one concern with the introduction of dynamic 
initialization and the pragma into the library. First, our 
(undocumented) design goal is to avoid requiring dynamic 
initialization in the library.

I.e., there should be no code in the library that runs at startup.
The rationale for it is efficiency and avoiding user code 
issues due to initialization dependencies. Since other 
libraries may use the same pragma, they will be subject to 
initialization dependencies that we try to avoid.


Unless there is a way to avoid the dynamic initialization or 
defer it until runtime (i.e., initialize the handler lazily) 


  We need initialize the handler before first operator new() call
(or from first oprator new() call), but I have not see the possible way
for this.


I wonder if defining DllMain() and setting the handler there,
for DLLs only, would deal with the initialization dependency
issue, albeit at the cost of a (small) runtime hit.

But given what we said about it being fixed in MSVC 8 I don't
think even this is worth the trouble. Not to mention that the
solution wouldn't work for archive libraries.

Martin

[jira] Commented: (STDCXX-77) [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure

[Martin Sebor (JIRA)]

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

Martin Sebor commented on STDCXX-77:


Just to clarify: Unless we accidentally stumble over a solution/workaround that 
doesn't require dynamic initialization I don't think we'll ever fix it given 
that it's caused by an MSVC 7.x bug that's fixed in MSVC 8.0.

> [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
> ---
>
> Key: STDCXX-77
> URL: https://issues.apache.org/jira/browse/STDCXX-77
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 18. Language Support
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: opnew.patch
>
>
> $ cat t.cpp && nmake t.exe && ./t
> #include 
> #include 
> #include 
> int main ()
> {
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
> int success = 0;
> try {
> operator new ((unsigned long)-1024);
> }
> catch (std::bad_alloc&) { success = 1; }
> catch (...) { }
> assert (success);
> }
> Microsoft (R) Program Maintenance Utility Version 7.10.3077
> Copyright (C) Microsoft Corporation.  All rights reserved.
> link  -nologo /NODEFAULTLIB:msvcprtd /debug 
> /LIBPATH:.\..\..\..\..\lib /OUT:t.exe  t.obj  testx15d_msvc_7_1.lib 
> tlt15d_msvc_7_1.lib std15d_msvc_7_1.lib user32.lib
> LINK : LNK6004: t.exe not found or not built by the last incremental link; 
> performing full link
> Assertion failed: success, file t.cpp, line 20
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.

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

issues against trunk, take 2 (was: Re: [jira] Closed: (STDCXX-515) std::basic_streambuf<>::xsputn() writes characters at the end, but not at the current position if reallocation of internal buffer occ

[Martin Sebor]

FYI: Unless we know for sure that we won't fix an issue in 4.2
the Affect Version/s shouldn't be 4.2 because 4.2 hasn't been
released yet.

We need to be able to track as accurately as we can which releases
were affected by each bug. It would also be helpful (for our own
internal purposes) to track regressions both introduced and fixed
during the same development cycle.

Suppose I am a user who wants to know which bugs have been reported
against the latest release I'm about to download, say 4.2, after it
comes out sometime in October. What do I search for? All bugs whose
Affect/s Versions contains 4.2. Here's what I get back from Jira:

http://tinyurl.com/2dy2az

What's my likely conclusion? That there are 19 bugs in the release.
I see that some of the have already been fixed but I need to look
at the Status field to see that *and* I also need to know to look
at the Fix Version/s field to see that they were fixed in the same
version. I then need to make the leap of figuring out that since
the Affects Version/s and Fix Version/s are the same, bugs for
which (Status==Resolved OR Status==Closed) AND Fix Versions IS
SUBSET OF Affect Versions holds don't really affect the tarball
I'm about to use.

As we briefly discussed a couple of weeks ago:
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg04242.html
we can either use "trunk" for the Version fields to avoid giving
users the impression that the releases are of worse quality than
they really are, or we can invent some other labeling scheme. I
don't think "trunk" is ideal because, as Andrew notes, it doesn't
make it immediately obvious which development cycle the regression
corresponds to. In addition, if the regression doesn't get fixed
in the same dev cycle, the Affected Version/s will need to be
reassigned to to the released version that contained the bug.
I'm not sure that's avoidable though.

So, does anyone have any better idea than using "trunk" for bugs
that do not affect any released versions?

Martin

Farid Zaripov (JIRA) wrote:

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

Farid Zaripov closed STDCXX-515.



The regression test added: http://svn.apache.org/viewvc?rev=570516&view=rev


std::basic_streambuf<>::xsputn() writes characters at the end, but not at the 
current position if reallocation of internal buffer occurs


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


The test below asserts on i == 512.
test.cpp:
--
#include 
#include 
#include 
int main ()
{
for (size_t i = 1; i <= 1024; ++i) {
std::stringstream strm;
std::string s (i, 'a');
strm << s;
strm.seekp (-1, std::ios::cur);
s.erase (0, 1);
strm << "bc";
s.append ("bc");
assert (strm.str () == s);
}
return 0;
}
--
The test output:
--
test: test.cpp:15: int main (): Assertion `strm.str () == s' failed.
Aborted
--

RE: [PATCH] STDCXX-77

[Farid Zaripov]

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Tuesday, August 28, 2007 7:11 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] STDCXX-77
> 
> I have one concern with the introduction of dynamic 
> initialization and the pragma into the library. First, our 
> (undocumented) design goal is to avoid requiring dynamic 
> initialization in the library.
> I.e., there should be no code in the library that runs at startup.
> The rationale for it is efficiency and avoiding user code 
> issues due to initialization dependencies. Since other 
> libraries may use the same pragma, they will be subject to 
> initialization dependencies that we try to avoid.
> 
> Unless there is a way to avoid the dynamic initialization or 
> defer it until runtime (i.e., initialize the handler lazily) 

  We need initialize the handler before first operator new() call
(or from first oprator new() call), but I have not see the possible way
for this.

> I would just as soon add the patch to the Jira issue and 
> close it as Won't Fix.

Farid.

[jira] Closed: (STDCXX-77) [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure

[Farid Zaripov (JIRA)]

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

Farid Zaripov closed STDCXX-77.
---

Resolution: Won't Fix

This issue won't be fixed for a while.

> [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
> ---
>
> Key: STDCXX-77
> URL: https://issues.apache.org/jira/browse/STDCXX-77
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 18. Language Support
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: opnew.patch
>
>
> $ cat t.cpp && nmake t.exe && ./t
> #include 
> #include 
> #include 
> int main ()
> {
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
> int success = 0;
> try {
> operator new ((unsigned long)-1024);
> }
> catch (std::bad_alloc&) { success = 1; }
> catch (...) { }
> assert (success);
> }
> Microsoft (R) Program Maintenance Utility Version 7.10.3077
> Copyright (C) Microsoft Corporation.  All rights reserved.
> link  -nologo /NODEFAULTLIB:msvcprtd /debug 
> /LIBPATH:.\..\..\..\..\lib /OUT:t.exe  t.obj  testx15d_msvc_7_1.lib 
> tlt15d_msvc_7_1.lib std15d_msvc_7_1.lib user32.lib
> LINK : LNK6004: t.exe not found or not built by the last incremental link; 
> performing full link
> Assertion failed: success, file t.cpp, line 20
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.

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

[jira] Updated: (STDCXX-77) [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure

[Farid Zaripov (JIRA)]

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

Farid Zaripov updated STDCXX-77:


Attachment: opnew.patch

Attached the possible patch.

> [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
> ---
>
> Key: STDCXX-77
> URL: https://issues.apache.org/jira/browse/STDCXX-77
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 18. Language Support
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2
>
> Attachments: opnew.patch
>
>
> $ cat t.cpp && nmake t.exe && ./t
> #include 
> #include 
> #include 
> int main ()
> {
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
> int success = 0;
> try {
> operator new ((unsigned long)-1024);
> }
> catch (std::bad_alloc&) { success = 1; }
> catch (...) { }
> assert (success);
> }
> Microsoft (R) Program Maintenance Utility Version 7.10.3077
> Copyright (C) Microsoft Corporation.  All rights reserved.
> link  -nologo /NODEFAULTLIB:msvcprtd /debug 
> /LIBPATH:.\..\..\..\..\lib /OUT:t.exe  t.obj  testx15d_msvc_7_1.lib 
> tlt15d_msvc_7_1.lib std15d_msvc_7_1.lib user32.lib
> LINK : LNK6004: t.exe not found or not built by the last incremental link; 
> performing full link
> Assertion failed: success, file t.cpp, line 20
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.

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

[jira] Issue Comment Edited: (STDCXX-260) configure-like script to configure library

[Eric Lemings (JIRA)]

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

elemings edited comment on STDCXX-260 at 8/28/07 11:27 AM:
---

For ease of reference, the attached file contains the help/usage message 
produced by a simple configure script.

Also, http://issues.apache.org/jira/browse/STDCXX-396 will resolve this issue.


  was (Author: elemings):
For ease of reference, the attached file contains the help/usage message 
produced by a simple configure script.
  
> configure-like script to configure library
> --
>
> Key: STDCXX-260
> URL: https://issues.apache.org/jira/browse/STDCXX-260
> Project: C++ Standard Library
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 4.1.2, 4.1.3
> Environment: UNIX
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>Priority: Critical
> Attachments: configure.out
>
>
> To make the configuration and build process more user-friendly we should 
> provide a configure-like script (as a wrapper around the existing 
> GNUmakefiles) to let users familiar with autoconf-based projects more quickly 
> configure, build, and install the library (including its headers). The script 
> should recognize and interpret the most common options such as --prefix=,  
> --enable-shared, --enable-threads, etc. by translating them to the existing 
> infrastructure's equivalents (e.g., BUILDMODE or BUILDTYPE).

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

[jira] Closed: (STDCXX-515) std::basic_streambuf<>::xsputn() writes characters at the end, but not at the current position if reallocation of internal buffer occurs

[Farid Zaripov (JIRA)]

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

Farid Zaripov closed STDCXX-515.



The regression test added: http://svn.apache.org/viewvc?rev=570516&view=rev

> std::basic_streambuf<>::xsputn() writes characters at the end, but not at the 
> current position if reallocation of internal buffer occurs
> 
>
> Key: STDCXX-515
> URL: https://issues.apache.org/jira/browse/STDCXX-515
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 27. Input/Output
>Affects Versions: 4.2
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The test below asserts on i == 512.
> test.cpp:
> --
> #include 
> #include 
> #include 
> int main ()
> {
> for (size_t i = 1; i <= 1024; ++i) {
> std::stringstream strm;
> std::string s (i, 'a');
> strm << s;
> strm.seekp (-1, std::ios::cur);
> s.erase (0, 1);
> strm << "bc";
> s.append ("bc");
> assert (strm.str () == s);
> }
> return 0;
> }
> --
> The test output:
> --
> test: test.cpp:15: int main (): Assertion `strm.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] Resolved: (STDCXX-515) std::basic_streambuf<>::xsputn() writes characters at the end, but not at the current position if reallocation of internal buffer occurs

[Farid Zaripov (JIRA)]

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

Farid Zaripov resolved STDCXX-515.
--

Resolution: Fixed

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

> std::basic_streambuf<>::xsputn() writes characters at the end, but not at the 
> current position if reallocation of internal buffer occurs
> 
>
> Key: STDCXX-515
> URL: https://issues.apache.org/jira/browse/STDCXX-515
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 27. Input/Output
>Affects Versions: 4.2
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The test below asserts on i == 512.
> test.cpp:
> --
> #include 
> #include 
> #include 
> int main ()
> {
> for (size_t i = 1; i <= 1024; ++i) {
> std::stringstream strm;
> std::string s (i, 'a');
> strm << s;
> strm.seekp (-1, std::ios::cur);
> s.erase (0, 1);
> strm << "bc";
> s.append ("bc");
> assert (strm.str () == s);
> }
> return 0;
> }
> --
> The test output:
> --
> test: test.cpp:15: int main (): Assertion `strm.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-539) [Sun C++ 5.9] std::uncaught_exception() false in terminate handler, SIGSEGV in std::unexpected

[Martin Sebor (JIRA)]

[Sun C++ 5.9] std::uncaught_exception() false in terminate handler, SIGSEGV in 
std::unexpected
--

 Key: STDCXX-539
 URL: https://issues.apache.org/jira/browse/STDCXX-539
 Project: C++ Standard Library
  Issue Type: Bug
  Components: External
 Environment: Sun C++ 5.9 (Sun Studio 12)
Reporter: Martin Sebor


 Original Message 
Subject: Re: (Incident Review ID: 1044672) std::uncaught_exception() false in 
terminate handler, SIGSEGV in std::unexpected
Date: Tue, 28 Aug 2007 11:10:28 -0700 (MST)
From: Steve Clamage <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

Hi Martin Sebor,

Thank you for reporting this issue.

We have determined that this report is a new bug and entered the bug into our 
internal bug tracking system under Bug Id: 6598218.

You can monitor this bug on the Java Bug Database at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6598218.

It may take a day or two before your bug shows up in this external database.  
If you are a member of the Sun Developer Network (SDN), there are two 
additional options once the bug is visible.

1. Voting for the bug
   Click http://bugs.sun.com/bugdatabase/addVote.do?bug_id=6598218.

2. Adding the report to your Bug Watch list.
   You will receive an email notification when this bug is updated.
   Click http://bugs.sun.com/bugdatabase/addBugWatch.do?bug_id=6598218.

The Sun Developer Network (http://developers.sun.com) is a free service that 
Sun offers.  To join, visit 
https://softwarereg.sun.com/registration/developer/en_US/new_user.

For a limited time, SDN members can obtain fully licensed Java IDEs for web and 
enterprise development.  More information is at 
http://developers.sun.com/prodtech/javatools/free/.

Regards,
Steve


NOTICE: This message, including any attachments, is for the intended
recipient(s) only.  If you are not the intended recipient(s), please
reply to the sender, delete this message, and refrain from disclosing,
copying, or distributing this message.

--- Previous Messages 


- Report -

  category : c++
   subcategory : library
   release : studio11
  type : bug
  synopsis : std::uncaught_exception() false in terminate handler, SIGSEGV 
in std::unexpected
 customer name : Martin Sebor
 customer mail : [EMAIL PROTECTED]
sdn id : 
  language : en
   company : Rogue Wave Software
  hardware : sun4
os : solaris_10
bug id : 6598218
  date created : Mon Aug 27 19:08:24 MST 2007
date evaluated : Tue Aug 28 11:07:08 MST 2007
   description : 
FULL PRODUCT VERSION :


ADDITIONAL OS VERSION INFORMATION :
Solaris 10

A DESCRIPTION OF THE PROBLEM :
According to 18.6.4, p1, std::uncaught_exception() is required to return true 
when terminate() is entered for any reason other than an explicit call to 
terminate(), and to continue to return true while executing the installed 
terminate handler. The program below shows that the Sun C++ implementation 
fails to follow this requirement.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile the test case below (named t.cpp) using CC t.cpp and run the executable.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
testing uncaught_exception() after a call to unexpected()
unexpected handler: uncaught_exception () == 0, got 0
PASS
uncaught_exception() after an implicit call to terminate()
terminate handler: uncaught_exception () == 1, got 1
PASS
uncaught_exception() after an explicit call to terminate()
terminate handler: uncaught_exception () == 0, got 0
PASS
uncaught_exception() after an explicit call to unexpected() during a throw
terminate handler: uncaught_exception () == 0, got 0
PASS

ACTUAL -
CC: Sun C++ 5.9 SunOS_sparc 2007/05/03
/amd/packages/mdx/solaris/SUNWspro/C++5.9/prod/bin/c++filt: Sun C++ 5.9 
SunOS_sparc 2007/05/03
ccfe: Sun C++ 5.9 SunOS_sparc 2007/05/03
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.482
testing uncaught_exception() after a call to unexpected()
unexpected handler: uncaught_exception () == 0, got 0
PASS
uncaught_exception() after an implicit call to terminate()
terminate handler: uncaught_exception () == 1, got 0
FAIL
uncaught_exception() after an explicit call to terminate()
terminate handler: uncaught_exception () == 0, got 0
PASS
uncaught_exception() after an explicit call to unexpected() during a throw
Segmentation Fault - core dumped
FAIL


REPRODUCIBILITY :
This bug can be reproduced always.

-- BEGIN SOURCE --
#include 
#include 
#include 

bool expect_uncaught;
const char* which;

void handler ()
{
const bool uncaught = std::uncaught_exception ();

printf ("%s handler: uncaugh

[jira] Updated: (STDCXX-396) GNU Release Support

[Eric Lemings (JIRA)]

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

Eric Lemings updated STDCXX-396:


Fix Version/s: 5.0
 Priority: Major  (was: Minor)

I'm going to finish this before 5.0 is released.

> GNU Release Support
> ---
>
> Key: STDCXX-396
> URL: https://issues.apache.org/jira/browse/STDCXX-396
> Project: C++ Standard Library
>  Issue Type: New Feature
>  Components: Build, Configuration
>Affects Versions: 4.1.3
>Reporter: Eric Lemings
> Fix For: 5.0
>
>
> This major feature adds support for GNU maintenance, distribution, and 
> release standards 
>  as 
> implemented by the GNU Autoconf, Automake, and Libtool software packages.   
> Note the operative word here: "adds".  This feature does not replace the 
> current configure and build scripts: it only supplements them.  (That is not 
> to say it may replace them in some future release however.)
> Rogue Wave people can find the latest work on this feature in my "pet 
> projects" directory under "stdcxx".  (You know where to look.)  Be aware 
> though: it is only about 2/3 complete.  Other interested parties can contact 
> me directly.

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

[jira] Commented: (STDCXX-528) create test 22.locale.money.get.mt.cpp

[Travis Vitek (JIRA)]

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

Travis Vitek commented on STDCXX-528:
-

2007-08-28  Travis Vitek  <[EMAIL PROTECTED]>

STDCXX-528
* 22.locale.money.get.mt.cpp: New test exercising the thread safety
of the std::money_get facet.


> create test 22.locale.money.get.mt.cpp
> --
>
> Key: STDCXX-528
> URL: https://issues.apache.org/jira/browse/STDCXX-528
> Project: C++ Standard Library
>  Issue Type: Sub-task
>  Components: 22. Localization, Thread Safety
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2
>
> Attachments: 22.locale.money.get.mt.cpp
>
>


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

[jira] Commented: (STDCXX-529) create test 22.locale.time.get.mt.cpp

[Travis Vitek (JIRA)]

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

Travis Vitek commented on STDCXX-529:
-

2007-08-28  Travis Vitek  <[EMAIL PROTECTED]>

STDCXX-529
* 22.locale.time.get.mt.cpp: New test exercising the thread safety
of the std::time_get facet.


> create test 22.locale.time.get.mt.cpp
> -
>
> Key: STDCXX-529
> URL: https://issues.apache.org/jira/browse/STDCXX-529
> Project: C++ Standard Library
>  Issue Type: Sub-task
>  Components: 22. Localization, Thread Safety
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2
>
> Attachments: 22.locale.time.get.mt.cpp
>
>


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

[PATCH] Use __rw_atomic_xxx() on Windows

[Farid Zaripov]

 Attached is a patch, adding __rw_atomic_{add|xchg}xx() functions on 
Win32/Win64 platforms.


 ChangeLog:
 * msvc-7.0.config: Added AS config variable.
 * msvc-8.0-x64.config: Ditto.
 * filterdef.js: Added definition of the CustomFileDef class
 * projectdef.js (InitAsmTool): New function to init custom build rule 
for .asm files.

 * projects.js: Added definitions of the platform dependent files.
 * utilities.js: Read AS configuration variable from the .config file.
 * i86/atomic.asm: New file with definitions of the __rw_atomic_xxx() 
for Win32 platform.
 * i86_64/atomic.asm: New file with definitions of the 
__rw_atomic_xxx() for Windows/x64 platform.

 * _mutex.h: Removed all dependencies on InterlockedXXX() API functions.
 Use new __rw_atomic_xxx() functions instead of InterlockedXXX().
 * once.cpp [_WIN32 && _DLL]: Tell linker to export __atomic_xxx()
 functions, defined in .asm files.

Farid.

Index: etc/config/windows/filterdef.js
===
--- etc/config/windows/filterdef.js (revision 570339)
+++ etc/config/windows/filterdef.js (working copy)
@@ -25,7 +25,7 @@
 
 var sourceFilterName = "Source Files";
 var sourceFilterUuid = "{4FC737F1-C7A5-4376-A066-2A32D752A2FF}";
-var sourceFilterExts = ".cpp;.cxx;.s";
+var sourceFilterExts = ".cpp;.cxx;.s;.asm";
 
 var headerFilterName = "Header Files";
 var headerFilterUuid = "{93995380-89BD-4b04-88EB-625FBE52EBFB}";
@@ -56,6 +56,21 @@
 return str;
 }
 
+//
+// CustomFileDef class
+//
+
+// CustomFileDef .ctor
+function CustomFileDef(filepath, platform, initfun)
+{
+this.filepath = filepath;
+this.platform = platform;
+this.initfun  = initfun;
+}
+
+// global array with platform dependent files definitions
+var customFileDefs = new Array();
+
 // common macros
 var cmnMacros = new Array();
 
@@ -126,7 +141,29 @@
 var VCFile = filter.AddFile(filename);
 if (null != filetype && typeof(VCFile.FileType) != "undefined")
 VCFile.FileType = filetype;
-
+
+var customFileDef = null;
+
+if (!exclude)
+{
+// find the platform dependent file definition
+for (var i = 0; i < customFileDefs.length; ++i)
+{
+var custFileDef = customFileDefs[i];
+var pos = VCFile.FullPath.length - custFileDef.filepath.length;
+if (0 <= pos && pos == 
VCFile.FullPath.indexOf(custFileDef.filepath))
+{
+customFileDef = custFileDef;
+break;
+}
+}
+
+// exclude this file from build if current platform
+// is not custom file target platform
+if (null != customFileDef && customFileDef.platform != PLATFORM)
+exclude = true;
+}
+
 if (exclude)
 {
 var cfgs = VCFile.FileConfigurations;
@@ -144,6 +181,12 @@
 cfg.ExcludedFromBuild = exclude;
 }
 }
+else if (null != customFileDef &&
+ "undefined" != typeof(customFileDef.initfun))
+{
+// init
+customFileDef.initfun(VCFile);
+}
 }
 
 // create VCFilter object from the FilterDef definition
Index: etc/config/windows/msvc-7.0.config
===
--- etc/config/windows/msvc-7.0.config  (revision 570339)
+++ etc/config/windows/msvc-7.0.config  (working copy)
@@ -38,6 +38,7 @@
 CXX=cl
 LD=cl
 AR=lib
+AS=ml
 
 // Use singlethreaded or mutlithreaded CRT in 11s, 11d solution configurations
 // 0 for MS VisualStudio .NET and MS VisualStudio .NET 2003
Index: etc/config/windows/msvc-8.0-x64.config
===
--- etc/config/windows/msvc-8.0-x64.config  (revision 570339)
+++ etc/config/windows/msvc-8.0-x64.config  (working copy)
@@ -1,2 +1,3 @@
 #include msvc-8.0
 PLATFORM=x64
+AS=ml64
Index: etc/config/windows/projectdef.js
===
--- etc/config/windows/projectdef.js(revision 570339)
+++ etc/config/windows/projectdef.js(working copy)
@@ -941,3 +941,25 @@
 
 return projectDef;
 }
+
+// init custom build rule for .asm files
+function InitAsmTool(VCFile)
+{
+var cfgs = VCFile.FileConfigurations;
+for (var i = 1; i <= cfgs.Count; ++i)
+{
+var cfg = cfgs.Item(i);
+if ((typeof(cfg.Tool.ToolKind) != "undefined" &&
+cfg.Tool.ToolKind != "VCCustomBuildTool") ||
+cfg.Tool.ToolName != "Custom Build Tool")
+{
+cfg.Tool = 
cfg.ProjectConfiguration.FileTools.Item("VCCustomBuildTool");
+}
+
+var tool = cfg.Tool;
+tool.Description = "Compiling .asm file...";
+tool.Outputs = "$(IntDir)\\$(InputName).obj";
+tool.CommandLine = AS + " /c /nologo /Fo" + tool.Outputs +
+   " /W3 /Zi /Ta" + VCFile.RelativePath;
+

Re: Exec utility test group reporting

[Andrew Black]

Mark Brown wrote:
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> Sent: Mon, 27 Aug 2007 09:11:51 -0600
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: Exec utility test group reporting
>>
>> Greetings Mark
>>
>> At this point, the validity, usability and accuracy of the Doxygen
>> comments in the exec utility is a theoretical exercise, as I don't think
>> anyone's ever taken the step of generating the documentation pages from
>> the source files.  That said, I've installed doxygen locally, and will
>> share the results if I have time to play with it.
> 
> Well, I tried generating documentation for the stdcxx/util directory to see 
> how Doxygen does. The result is published on my home page: 
> http://mark.g.brown.googlepages.com/stdcxxutil. This is my first attempt to 
> use the site so pardon the appearance of the entry page. In my opinion, it 
> doesn't look half bad, don't you think?

Ascetically the pages look decent (with the exception of a 404 on
http://mark.g.brown.googlepages.com/structtarget__opts.html ), however
they feel a little light on content.  Is there a switch to get doxygen
to generate the documentation for variables and functions outside of
classes?  The bulk of the documentation for the exec utility is in these
areas, rather than the structs which are used to pass data around.  (Is
there a C mode that you could force doxygen to use?  The exec utility
was written as a C program, though the files were given a .cpp suffix so
they could build with the infrastructure.)

> 
>> It would likely make sense to eventually store the generated docs
>> somewhere in subversion, but the potential problem of documentation
>> drift exists.  I suppose this shouldn't count as a strike against using
>> Doxygen, as that potential exists for all documentation.
> 
> Would generating the documentation automatically be a solution?

That would be a solution, but as best I can tell, you'd have to do the
regeneration on the subversion server as part of a commit script, and I
don't know if we have the ability to set such things up.

--Andrew Black

Re: [RFC] draft stdcxx resolution for the Board

[Martin Sebor]

Eric Lemings wrote:
 


-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 27, 2007 7:29 PM

To: stdcxx-dev@incubator.apache.org
Subject: Re: [RFC] draft stdcxx resolution for the Board

Eric Lemings wrote:
 


-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 27, 2007 2:59 PM

To: stdcxx-dev@incubator.apache.org
Subject: [RFC] draft stdcxx resolution for the Board

I'm working on the Board resolution based on the following page:

http://incubator.apache.org/guides/graduation.html#tlp-resolution

and I have a few issues I need help with. I'm hoping that our
mentors can give us guidance here, although I certainly encourage
everyone else, most of all committers, to read through this and
provide feedback.


1. Official project name: Apache C++ Standard Library

I have always assumed that the official name of our project is
the Apache C++ Standard Library, and that STDCXX is an "acronym"
or "keyword" (e.g., the same way APR is to the Apache Portable
Runtime Project). I'm not 100% sure that everyone shares the
same view so I'm looking for a confirmation that "Apache C++
Standard Library" is an acceptable name to use in the resolution.
(The attached proposed resolution assumes the answer is
affirmative.)

I agree with the canonical name.  As for the acronym, I'd like to
propose "ASL".

Not ASCXXL? ;-)


Too clever I guess, some may say obfuscated.  :-P


I'm not sure if we can easily change this or even that we should
try. What would happen to Jira or mailing lists? I suppose lists
could have aliases, but it might be additional work for the infra
team.

But if you're serious about it go ahead and make a formal proposal
to change it. Far be if for me to discourage you but I expect you
will need to have a really compelling rationale to convince
everyone, especially the rest of the Incubator, that it's a good
idea.


Good idea?  Not sure.  Better acronym?  I think so.


I agree it's easier to pronounce and probably will be easier to
remember. If it was easy to change I'd be all for it. The issue
is that a) I don't know how easy it would be to change, and b)
I may not have the bandwidth to try to find out. If you would
like to try I'll support you but you'll have to do the legwork.
I.e., find out (either from our mentors or from the rest of the
Incubator) how difficult such a change would be, how we would
go about implementing it, and by how long it would delay our
graduation.



Hypothetical scenario: another acronym is proposed, be it "ASL" or
whatever, and it is well received.  Unanimously in fact.

Would all this required work still be worth the change?  If the answer
is yes, then it's a good idea.

I just have the feeling that people will associate "STDCXX" more with
Rogue Wave Software rather than the Apache Foundation.  So in that
respect, ANY new acronym will be a better choice.


I'm not sure I see why that would be the case. We (Rogue Wave)
have made it clear that stdcxx is the Apache implementation of
the C++ Standard Library:

  http://www.roguewave.com/standard-library/

Martin

Re: [PATCH] STDCXX-77

[Martin Sebor]

Farid Zaripov wrote:
 Attached is a patch to make operator new on MSVC conforming to the C++ 
Standard.


I have one concern with the introduction of dynamic initialization
and the pragma into the library. First, our (undocumented) design
goal is to avoid requiring dynamic initialization in the library.
I.e., there should be no code in the library that runs at startup.
The rationale for it is efficiency and avoiding user code issues
due to initialization dependencies. Since other libraries may use
the same pragma, they will be subject to initialization dependencies
that we try to avoid.

Unless there is a way to avoid the dynamic initialization or defer
it until runtime (i.e., initialize the handler lazily) I would just
as soon add the patch to the Jira issue and close it as Won't Fix.

Martin


 ChangeLog:
 * _config-msvcrt.h: #undefine _RWSTD_NO_NEW_THROWS and
 _RWSTD_NO_NEW_OFLOW_SAFE macros if they're #defined.
 * memory.cpp (__rw_new_handler_imp): Throw std::bad_alloc() if no user 
handler installed.

 (set_new_handler): Don't invoke _set_new_handler().
 * new_supp.cpp: New file with helper object to make operator new
 conforming to the C++ Standard

Farid.




Index: include/rw/_config-msvcrt.h
===
--- include/rw/_config-msvcrt.h (revision 570339)
+++ include/rw/_config-msvcrt.h (working copy)
@@ -148,6 +148,14 @@
 #  define _RWSTD_NO_DEPRECATED_C_HEADERS
 #endif   // _RWSTD_NO_DEPRECATED_C_HEADERS
 
+#ifdef _RWSTD_NO_NEW_THROWS

+#  undef _RWSTD_NO_NEW_THROWS
+#endif   // _RWSTD_NO_NEW_THROWS
+
+#ifdef _RWSTD_NO_NEW_OFLOW_SAFE
+#  undef _RWSTD_NO_NEW_OFLOW_SAFE
+#endif   // _RWSTD_NO_NEW_OFLOW_SAFE
+
// operator new and delete is not reliably replaceable across
// shared library boundaries, which includes the shared library
// version of the language support library
Index: src/memory.cpp
===
--- src/memory.cpp  (revision 570339)
+++ src/memory.cpp  (working copy)
@@ -178,20 +178,22 @@
 
 #ifdef _MSC_VER
 
-typedef int (*__rw_new_handler_t)(_RWSTD_SIZE_T);

-
-_RWSTD_DLLIMPORT __rw_new_handler_t _set_new_handler (__rw_new_handler_t);
-
 _RWSTD_NAMESPACE (__rw) {
 
 static _STD::new_handler __rw_new_handler /* = 0 */;
 
-static int __rw_new_handler_imp (_RWSTD_SIZE_T)

+int __rw_new_handler_imp (_RWSTD_SIZE_T)
 {
-_RWSTD_ASSERT (0 != __rw_new_handler);
+if (!__rw_new_handler)
+#if _MSC_VER <= 1310
+_RW::__rw_throw (_RWSTD_ERROR_FIRST + 3 /* == bad_alloc */);
+#else
+return 0;   // operator new will throw std::bad_alloc()
+#endif
 
 __rw_new_handler ();
 
+// repeat memory allocation

 return 1;
 }
 
@@ -214,8 +216,6 @@
 
 _RW::__rw_new_handler = handler;
 
-_set_new_handler (_RW::__rw_new_handler_imp);

-
 return save;
 }
 
Index: src/new_supp.cpp

===
--- src/new_supp.cpp(revision 0)
+++ src/new_supp.cpp(revision 0)
@@ -0,0 +1,58 @@
+ /***
+ *
+ * new_supp.cpp - helper object to make operator new conforming
+ *to the C++ Standard
+ *
+ * $Id$
+ *
+ ***
+ *
+ * Licensed to the Apache Software  Foundation (ASF) under one or more
+ * contributor  license agreements.  See  the NOTICE  file distributed
+ * with  this  work  for  additional information  regarding  copyright
+ * ownership.   The ASF  licenses this  file to  you under  the Apache
+ * License, Version  2.0 (the  License); you may  not use  this file
+ * except in  compliance with the License.   You may obtain  a copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the  License is distributed on an  "AS IS" BASIS,
+ * WITHOUT  WARRANTIES OR CONDITIONS  OF ANY  KIND, either  express or
+ * implied.   See  the License  for  the  specific language  governing
+ * permissions and limitations under the License.
+ *
+ **/
+
+#define _RWSTD_LIB_SRC
+
+#ifdef _MSC_VER
+
+#include 
+
+
+typedef int (*__rw_new_handler_t)(_RWSTD_SIZE_T);
+
+_RWSTD_DLLIMPORT __rw_new_handler_t _set_new_handler (__rw_new_handler_t);
+
+_RWSTD_NAMESPACE (__rw) {
+
+int __rw_new_handler_imp (_RWSTD_SIZE_T);
+
+}   // namespace __rw
+
+
+#pragma init_seg (lib)
+
+struct __rw_new_handler_init_t
+{
+__rw_new_handler_init_t () {
+_set_new_handler (_RW::__rw_new_handler_imp);
+}
+};
+
+static __rw_new_handler_init_t __rw_new_handler_init;
+
+
+#endif   // _MSC_VER

Property changes on: src\new_supp.cpp
___
Name: svn:key

[jira] Resolved: (STDCXX-272) [LWG #625] std::string::find_first_of() returns 0 for the empty string

[Farid Zaripov (JIRA)]

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

Farid Zaripov resolved STDCXX-272.
--

Resolution: Fixed

Yes. This issue is a part of the STDCXX-466 issue and fixed by patch for 
STDCXX-466.

> [LWG #625] std::string::find_first_of() returns 0 for the empty string
> --
>
> Key: STDCXX-272
> URL: https://issues.apache.org/jira/browse/STDCXX-272
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The program below is expected to run succeffully to completion (since the 
> returned value must be less than the size of the string) but instead it 
> aborts.
> $ cat t.cpp && nice gmake t && ./t
> #include 
> #include 
> int main ()
> {
> std::string::size_type xpos =
> std::string ("").find_first_of ("cba", 0, std::string::npos);
> assert (std::string::npos == xpos);
> }
> aCC -c -I/amd/devco/sebor/dev/stdlib/include/ansi -I/usr/include  
> -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG -I/amd/devco/sebor/dev/stdlib/include 
> -I/build/sebor/aCC-3.70-11d/include 
> -I/amd/devco/sebor/dev/stdlib/examples/include  -Aa +nostl  -g +d  +w +W392 
> +W655 +W684 +W818 +W819 +W849  t.cpp
> aCC t.o -o t -Aa +nostl -Wl,+s -Wl,+vnocompatwarnings 
> -L/build/sebor/aCC-3.70-11d/lib-L/build/sebor/aCC-3.70-11d/lib -lstd11d   
> -lm
> ABORT instruction (core dumped)

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

[jira] Closed: (STDCXX-272) [LWG #625] std::string::find_first_of() returns 0 for the empty string

[Farid Zaripov (JIRA)]

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

Farid Zaripov closed STDCXX-272.



> [LWG #625] std::string::find_first_of() returns 0 for the empty string
> --
>
> Key: STDCXX-272
> URL: https://issues.apache.org/jira/browse/STDCXX-272
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The program below is expected to run succeffully to completion (since the 
> returned value must be less than the size of the string) but instead it 
> aborts.
> $ cat t.cpp && nice gmake t && ./t
> #include 
> #include 
> int main ()
> {
> std::string::size_type xpos =
> std::string ("").find_first_of ("cba", 0, std::string::npos);
> assert (std::string::npos == xpos);
> }
> aCC -c -I/amd/devco/sebor/dev/stdlib/include/ansi -I/usr/include  
> -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG -I/amd/devco/sebor/dev/stdlib/include 
> -I/build/sebor/aCC-3.70-11d/include 
> -I/amd/devco/sebor/dev/stdlib/examples/include  -Aa +nostl  -g +d  +w +W392 
> +W655 +W684 +W818 +W819 +W849  t.cpp
> aCC t.o -o t -Aa +nostl -Wl,+s -Wl,+vnocompatwarnings 
> -L/build/sebor/aCC-3.70-11d/lib-L/build/sebor/aCC-3.70-11d/lib -lstd11d   
> -lm
> ABORT instruction (core dumped)

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

[jira] Updated: (STDCXX-466) basic_string<>::rfind() and basic_string<>::find_xxx() methods throws length_error(), but shouldn't

[Farid Zaripov (JIRA)]

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

Farid Zaripov updated STDCXX-466:
-

Fix Version/s: 4.2
Affects Version/s: (was: 4.2)
   4.1.3
   4.1.4

> basic_string<>::rfind() and basic_string<>::find_xxx() methods throws 
> length_error(), but shouldn't
> ---
>
> Key: STDCXX-466
> URL: https://issues.apache.org/jira/browse/STDCXX-466
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.1.3, 4.1.4
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The details are here: 
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03795.html

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

[jira] Updated: (STDCXX-272) [LWG #625] std::string::find_first_of() returns 0 for the empty string

[Farid Zaripov (JIRA)]

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

Farid Zaripov updated STDCXX-272:
-

Fix Version/s: 4.2

> [LWG #625] std::string::find_first_of() returns 0 for the empty string
> --
>
> Key: STDCXX-272
> URL: https://issues.apache.org/jira/browse/STDCXX-272
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The program below is expected to run succeffully to completion (since the 
> returned value must be less than the size of the string) but instead it 
> aborts.
> $ cat t.cpp && nice gmake t && ./t
> #include 
> #include 
> int main ()
> {
> std::string::size_type xpos =
> std::string ("").find_first_of ("cba", 0, std::string::npos);
> assert (std::string::npos == xpos);
> }
> aCC -c -I/amd/devco/sebor/dev/stdlib/include/ansi -I/usr/include  
> -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG -I/amd/devco/sebor/dev/stdlib/include 
> -I/build/sebor/aCC-3.70-11d/include 
> -I/amd/devco/sebor/dev/stdlib/examples/include  -Aa +nostl  -g +d  +w +W392 
> +W655 +W684 +W818 +W819 +W849  t.cpp
> aCC t.o -o t -Aa +nostl -Wl,+s -Wl,+vnocompatwarnings 
> -L/build/sebor/aCC-3.70-11d/lib-L/build/sebor/aCC-3.70-11d/lib -lstd11d   
> -lm
> ABORT instruction (core dumped)

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

RE: [RFC] draft stdcxx resolution for the Board

[Eric Lemings]

 

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Monday, August 27, 2007 7:29 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [RFC] draft stdcxx resolution for the Board
> 
> Eric Lemings wrote:
> >  
> > 
> >> -Original Message-
> >> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> >> Sent: Monday, August 27, 2007 2:59 PM
> >> To: stdcxx-dev@incubator.apache.org
> >> Subject: [RFC] draft stdcxx resolution for the Board
> >>
> >> I'm working on the Board resolution based on the following page:
> >>
> >> http://incubator.apache.org/guides/graduation.html#tlp-resolution
> >>
> >> and I have a few issues I need help with. I'm hoping that our
> >> mentors can give us guidance here, although I certainly encourage
> >> everyone else, most of all committers, to read through this and
> >> provide feedback.
> >>
> >>
> >> 1. Official project name: Apache C++ Standard Library
> >>
> >> I have always assumed that the official name of our project is
> >> the Apache C++ Standard Library, and that STDCXX is an "acronym"
> >> or "keyword" (e.g., the same way APR is to the Apache Portable
> >> Runtime Project). I'm not 100% sure that everyone shares the
> >> same view so I'm looking for a confirmation that "Apache C++
> >> Standard Library" is an acceptable name to use in the resolution.
> >> (The attached proposed resolution assumes the answer is
> >> affirmative.)
> > 
> > I agree with the canonical name.  As for the acronym, I'd like to
> > propose "ASL".
> 
> Not ASCXXL? ;-)

Too clever I guess, some may say obfuscated.  :-P

> I'm not sure if we can easily change this or even that we should
> try. What would happen to Jira or mailing lists? I suppose lists
> could have aliases, but it might be additional work for the infra
> team.
> 
> But if you're serious about it go ahead and make a formal proposal
> to change it. Far be if for me to discourage you but I expect you
> will need to have a really compelling rationale to convince
> everyone, especially the rest of the Incubator, that it's a good
> idea.

Good idea?  Not sure.  Better acronym?  I think so.

Hypothetical scenario: another acronym is proposed, be it "ASL" or
whatever, and it is well received.  Unanimously in fact.

Would all this required work still be worth the change?  If the answer
is yes, then it's a good idea.

I just have the feeling that people will associate "STDCXX" more with
Rogue Wave Software rather than the Apache Foundation.  So in that
respect, ANY new acronym will be a better choice.

EBL.

[jira] Updated: (STDCXX-455) [Cygwin] localedef errors: fatal error - could not load shell32, Win32 error 487

[Farid Zaripov (JIRA)]

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

Farid Zaripov updated STDCXX-455:
-

Fix Version/s: (was: 4.2)
   4.3

Deffered to 4.3 version.

> [Cygwin] localedef errors: fatal error - could not load shell32, Win32 error 
> 487
> 
>
> Key: STDCXX-455
> URL: https://issues.apache.org/jira/browse/STDCXX-455
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Locales
> Environment: Cygwin
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.3
>
>
> ar_IN.UTF-8, de_DE.UTF-8 and en_IN.UTF-8 locales are failed:
>5437 [main] localedef 3260 
> d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - 
> could not load shell32, Win32 error 487
> /bin/sh: line 5: 3260 Hangup ./localedef -w -c -f 
> /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i 
> /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname 
> /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/ar_IN.UTF-8
> make: *** [ar_IN.UTF-8] Error 129
>   5 [main] localedef 3444 
> d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - 
> could not load shell32, Win32 error 487
> /bin/sh: line 5: 3444 Hangup ./localedef -w -c -f 
> /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i 
> /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname 
> /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/de_DE.UTF-8
> make: *** [de_DE.UTF-8] Error 129
>   5 [main] localedef 3952 
> d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - 
> could not load shell32, Win32 error 487
> /bin/sh: line 5: 3952 Hangup ./localedef -w -c -f 
> /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i 
> /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname 
> /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/en_IN.UTF-8
> make: *** [en_IN.UTF-8] Error 129 

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

[jira] Updated: (STDCXX-517) No required options for generate.bat script

[Farid Zaripov (JIRA)]

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

Farid Zaripov updated STDCXX-517:
-

Fix Version/s: 4.2

Scheduled to version 4.2.

> No required options for generate.bat script
> ---
>
> Key: STDCXX-517
> URL: https://issues.apache.org/jira/browse/STDCXX-517
> Project: C++ Standard Library
>  Issue Type: Improvement
>Affects Versions: 4.1.3
> Environment: All Windows platforms
>Reporter: Eric Lemings
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The generate.bat script currently requires two options: /BUILDDIR and 
> /CONFIG.  Unless there's a valid reason NOT to do so, the generate.bat script 
> should preset or determine the following values for these options when the 
> user does not specify their own value.  /BUILDDIR should default to the 
> source directory; that is, the same directory containing the generate.bat 
> script.  For the /CONFIG option, the script should probe the build 
> environment for all possible/supported Windows compilers currently installed 
> and then sanity check each one that is found.  If it finds no sane compilers, 
> the script should probably issue a warning and just exit.  If only one 
> compiler is found, configure all distribution files to build with that 
> compiler.  If more than one compiler is found, set the target compiler to the 
> first one found in predefined order of preference.  (This order could be for 
> instance, MSVC 8, 7, ..., Intel C++ 10, 9, 8, etc, Cygwin GCC, Mingw, 
> Borland, etc.)

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

[jira] Updated: (STDCXX-77) [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure

[Farid Zaripov (JIRA)]

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

Farid Zaripov updated STDCXX-77:


Fix Version/s: 4.2

> [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
> ---
>
> Key: STDCXX-77
> URL: https://issues.apache.org/jira/browse/STDCXX-77
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 18. Language Support
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> $ cat t.cpp && nmake t.exe && ./t
> #include 
> #include 
> #include 
> int main ()
> {
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
> int success = 0;
> try {
> operator new ((unsigned long)-1024);
> }
> catch (std::bad_alloc&) { success = 1; }
> catch (...) { }
> assert (success);
> }
> Microsoft (R) Program Maintenance Utility Version 7.10.3077
> Copyright (C) Microsoft Corporation.  All rights reserved.
> link  -nologo /NODEFAULTLIB:msvcprtd /debug 
> /LIBPATH:.\..\..\..\..\lib /OUT:t.exe  t.obj  testx15d_msvc_7_1.lib 
> tlt15d_msvc_7_1.lib std15d_msvc_7_1.lib user32.lib
> LINK : LNK6004: t.exe not found or not built by the last incremental link; 
> performing full link
> Assertion failed: success, file t.cpp, line 20
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.

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

[jira] Updated: (STDCXX-451) Improve the checking of the ANSI C library functions

[Farid Zaripov (JIRA)]

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

Farid Zaripov updated STDCXX-451:
-

Fix Version/s: 4.3

> Improve the checking of the ANSI C library functions
> 
>
> Key: STDCXX-451
> URL: https://issues.apache.org/jira/browse/STDCXX-451
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: Configuration
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
>Priority: Minor
> Fix For: 4.3
>
>
> Perform checking of all declarations in one step, and fallback  to the 
> current algorithm is the first attempt failed.
> The additional info: 
> http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200706.mbox/[EMAIL
>  PROTECTED]

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

[jira] Assigned: (STDCXX-79) [MSVC 7] operator new doesn't throw on failure

[Farid Zaripov (JIRA)]

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

Farid Zaripov reassigned STDCXX-79:
---

Assignee: Farid Zaripov

> [MSVC 7] operator new doesn't throw on failure
> --
>
> Key: STDCXX-79
> URL: https://issues.apache.org/jira/browse/STDCXX-79
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: External
>Affects Versions: 4.1.2
> Environment: MSVC 7.0, 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Critical
>
> The implementation of operaror new in the MSVC 7 runtime library (but not the 
> one in the C++ Standard Library, msvcprtd), fails to throw an exception on 
> failure and instead returns 0. This works correctly in MSVC 8.
> Here's a reference to the MSVC 7 documentation of their libraries:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp
> $ cat t.cpp && cl /EHsc /MDd t.cpp /c && link /NODEFAULTLIB:msvcprtd t.obj && 
> ./t
> #include 
> #include 
> #include 
> int main ()
> {
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
> int success = 0;
> try {
> operator new ((unsigned long)-1024);
> }
> catch (std::bad_alloc&) { success = 1; }
> catch (...) { }
> assert (success);
> }
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
> t.cpp
> Microsoft (R) Incremental Linker Version 7.10.3077
> Copyright (C) Microsoft Corporation. All rights reserved.
> Assertion failed: success, file t.cpp, line 20
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.

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

[PATCH] STDCXX-77

[Farid Zaripov]

 Attached is a patch to make operator new on MSVC conforming to the C++ 
Standard.


 ChangeLog:
 * _config-msvcrt.h: #undefine _RWSTD_NO_NEW_THROWS and
 _RWSTD_NO_NEW_OFLOW_SAFE macros if they're #defined.
 * memory.cpp (__rw_new_handler_imp): Throw std::bad_alloc() if no user 
handler installed.

 (set_new_handler): Don't invoke _set_new_handler().
 * new_supp.cpp: New file with helper object to make operator new
 conforming to the C++ Standard

Farid.

Index: include/rw/_config-msvcrt.h
===
--- include/rw/_config-msvcrt.h (revision 570339)
+++ include/rw/_config-msvcrt.h (working copy)
@@ -148,6 +148,14 @@
 #  define _RWSTD_NO_DEPRECATED_C_HEADERS
 #endif   // _RWSTD_NO_DEPRECATED_C_HEADERS
 
+#ifdef _RWSTD_NO_NEW_THROWS
+#  undef _RWSTD_NO_NEW_THROWS
+#endif   // _RWSTD_NO_NEW_THROWS
+
+#ifdef _RWSTD_NO_NEW_OFLOW_SAFE
+#  undef _RWSTD_NO_NEW_OFLOW_SAFE
+#endif   // _RWSTD_NO_NEW_OFLOW_SAFE
+
// operator new and delete is not reliably replaceable across
// shared library boundaries, which includes the shared library
// version of the language support library
Index: src/memory.cpp
===
--- src/memory.cpp  (revision 570339)
+++ src/memory.cpp  (working copy)
@@ -178,20 +178,22 @@
 
 #ifdef _MSC_VER
 
-typedef int (*__rw_new_handler_t)(_RWSTD_SIZE_T);
-
-_RWSTD_DLLIMPORT __rw_new_handler_t _set_new_handler (__rw_new_handler_t);
-
 _RWSTD_NAMESPACE (__rw) {
 
 static _STD::new_handler __rw_new_handler /* = 0 */;
 
-static int __rw_new_handler_imp (_RWSTD_SIZE_T)
+int __rw_new_handler_imp (_RWSTD_SIZE_T)
 {
-_RWSTD_ASSERT (0 != __rw_new_handler);
+if (!__rw_new_handler)
+#if _MSC_VER <= 1310
+_RW::__rw_throw (_RWSTD_ERROR_FIRST + 3 /* == bad_alloc */);
+#else
+return 0;   // operator new will throw std::bad_alloc()
+#endif
 
 __rw_new_handler ();
 
+// repeat memory allocation
 return 1;
 }
 
@@ -214,8 +216,6 @@
 
 _RW::__rw_new_handler = handler;
 
-_set_new_handler (_RW::__rw_new_handler_imp);
-
 return save;
 }
 
Index: src/new_supp.cpp
===
--- src/new_supp.cpp(revision 0)
+++ src/new_supp.cpp(revision 0)
@@ -0,0 +1,58 @@
+ /***
+ *
+ * new_supp.cpp - helper object to make operator new conforming
+ *to the C++ Standard
+ *
+ * $Id$
+ *
+ ***
+ *
+ * Licensed to the Apache Software  Foundation (ASF) under one or more
+ * contributor  license agreements.  See  the NOTICE  file distributed
+ * with  this  work  for  additional information  regarding  copyright
+ * ownership.   The ASF  licenses this  file to  you under  the Apache
+ * License, Version  2.0 (the  License); you may  not use  this file
+ * except in  compliance with the License.   You may obtain  a copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the  License is distributed on an  "AS IS" BASIS,
+ * WITHOUT  WARRANTIES OR CONDITIONS  OF ANY  KIND, either  express or
+ * implied.   See  the License  for  the  specific language  governing
+ * permissions and limitations under the License.
+ *
+ **/
+
+#define _RWSTD_LIB_SRC
+
+#ifdef _MSC_VER
+
+#include 
+
+
+typedef int (*__rw_new_handler_t)(_RWSTD_SIZE_T);
+
+_RWSTD_DLLIMPORT __rw_new_handler_t _set_new_handler (__rw_new_handler_t);
+
+_RWSTD_NAMESPACE (__rw) {
+
+int __rw_new_handler_imp (_RWSTD_SIZE_T);
+
+}   // namespace __rw
+
+
+#pragma init_seg (lib)
+
+struct __rw_new_handler_init_t
+{
+__rw_new_handler_init_t () {
+_set_new_handler (_RW::__rw_new_handler_imp);
+}
+};
+
+static __rw_new_handler_init_t __rw_new_handler_init;
+
+
+#endif   // _MSC_VER

Property changes on: src\new_supp.cpp
___
Name: svn:keywords
   + Id
Name: svn:eol-style
   + native

[jira] Commented: (STDCXX-77) [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure

[Farid Zaripov (JIRA)]

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

Farid Zaripov commented on STDCXX-77:
-

The possible way (which disables user to use _set_new_handler() and 
_set_new_mode() functions) is install CRT new handler (using 
_set_new_handler()) at library initialization and throw std::bad_alloc from 
there. This way is described here: http://support.microsoft.com/?kbid=167733

> [MSVC 7.1] operator new doesn't throw std::bad_alloc on failure
> ---
>
> Key: STDCXX-77
> URL: https://issues.apache.org/jira/browse/STDCXX-77
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 18. Language Support
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
> Environment: MSVC 7.1
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>
> $ cat t.cpp && nmake t.exe && ./t
> #include 
> #include 
> #include 
> int main ()
> {
> _CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
> _CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
> int success = 0;
> try {
> operator new ((unsigned long)-1024);
> }
> catch (std::bad_alloc&) { success = 1; }
> catch (...) { }
> assert (success);
> }
> Microsoft (R) Program Maintenance Utility Version 7.10.3077
> Copyright (C) Microsoft Corporation.  All rights reserved.
> link  -nologo /NODEFAULTLIB:msvcprtd /debug 
> /LIBPATH:.\..\..\..\..\lib /OUT:t.exe  t.obj  testx15d_msvc_7_1.lib 
> tlt15d_msvc_7_1.lib std15d_msvc_7_1.lib user32.lib
> LINK : LNK6004: t.exe not found or not built by the last incremental link; 
> performing full link
> Assertion failed: success, file t.cpp, line 20
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.

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

[jira] Updated: (STDCXX-507) Access violation while loading libstdxxx.dll in dynamic builds on Cygwin

[Farid Zaripov (JIRA)]

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

Farid Zaripov updated STDCXX-507:
-

Fix Version/s: 4.2.1

> Access violation while loading libstdxxx.dll in dynamic builds on Cygwin
> 
>
> Key: STDCXX-507
> URL: https://issues.apache.org/jira/browse/STDCXX-507
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 4.2
> Environment: gcc 3.4.4/Cygwin
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
> Attachments: localedef.imports
>
>
> Many utilities, examples and tests failed to start due to access violation 
> while loading libstdxxx.dll. In night builds logs they all finished with 
> status 5. The reason is access violation while loading libstdxxx.dll. All of 
> them has many times duplicated imports (see the attached file) and I suppose 
> that bug in ld utility.
> 
> $ ./localedef || echo $?
> 5
> $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef
> --- Process 732, exception C005 at 7C919994
> --- Process 732, exception C005 at 7C964ED1
> 

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

[jira] Updated: (STDCXX-430) building Boost with stdcxx

[Farid Zaripov (JIRA)]

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

Farid Zaripov updated STDCXX-430:
-

Fix Version/s: (was: 4.2)
   4.2.1

> building Boost with stdcxx
> --
>
> Key: STDCXX-430
> URL: https://issues.apache.org/jira/browse/STDCXX-430
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: External
>Affects Versions: 4.2
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Critical
> Fix For: 4.2.1
>
>
> This is a placeholder issue to make it possible and easy to build the Boost 
> libraries on top of stdcxx.
> Each stdcxx bug revealed by Boost must have an issue. The issue should be 
> linked to this one.
> Changes contributed to Boost (such as stdcxx .jam files) should be tracked as 
> subtasks of this issue.
> Each bug in Boost should be filed in the Boost bug tracking database and 
> cross-referenced in comments on this issue.
> See the following threads for details of the project:
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html

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