Re: STDCXX progress to graduation
William A. Rowe, Jr. wrote: Noel J. Bergman wrote: William A. Rowe, Jr. wrote: [...] things are as quiet as expected for a mature implementation of a reference standard. Any concern that because of the maturity, it could stagnate and lose community? Not at this time. Because it is widely deployed, there will be a long term demand. Because it's transparent to the developer, and in debugging their apps they can drill right into flaws within stdcxx, I suspect we will see bug feedback folks turn patchers turn contributors turn project members for years, as long as C++ is a widely adopted language. I have little to add to Bill and Justin's encouraging comments, except that the C++ standard is currently being revised and a new, significantly extended one is close to being completed, and is expected to be ratified in the 2010 timeframe. Many new features have already been added to the standard and more still are in the works. We are looking forward to fully implementing all of the new components after the upcoming 4.2 release of stdcxx. We expect to attract even more users to the project with this milestone release, and to grow the community of contributors in the coming months to help us with the implementation of the many new features. Graduating from the incubator will be a crucial step in reaching these goals and ensuring an wider adoption of the project. Martin
Getting incorrect behavior on strstream
I have a testcase that is showing incorrect behavior ostrstream or ostringstream: #include #include #include #include #include #include void test1() { std::ostringstream S; long double x = std::pow(1e300,2); S << "Something " << std::setprecision(8) << x; S << " else"; std::printf("Test1: %s\n", S.str().c_str()); } void test2() { std::ostrstream S; long double x = std::pow(1e300,2); S << "Something " << std::setprecision(7) << x; S << " else"; std::printf("Test2: %s\n", S.str()); } void test3() { std::ostrstream S; long double x = 0.0/0.0; S << "Something " << std::setprecision(8) << x; S << " else"; std::printf("Test3: %s\n", S.str()); } int main(int argc, char* argv[]) { test1(); test2(); test3(); } On solaris 8 with Sun Studio 8 patch 14 I get the following output Test1: Something inf Test2: Something inf else else Test3: Something nan else Test1 is missing else Test2 has an extra else Test3 looks ok. On RedHat 3u6 I get the following output: Test1: Something inf else Test2: Something inf else Test3: Something nan elseing inf else Test1 and 2 look ok Test3 however has extra output "ing inf else" Any thoughts on this problem? Thanks, Jeremy Jeremy Dean Rogue Wave Software, A QUOVADX(tm) division Technical Support Phone: 303-545-3205 -- 1-800-404-4767 E-mail: [EMAIL PROTECTED] Web: http://www.roguewave.com/support Knowledge Base entries: http://www.roguewave.com/kbdocs/search.html View issues online at: http://www.roguewave.com/youraccount/login/
[jira] Created: (STDCXX-456) [Intel Thread Checker] infinite loop on 22.time.put.mt
[Intel Thread Checker] infinite loop on 22.time.put.mt -- Key: STDCXX-456 URL: https://issues.apache.org/jira/browse/STDCXX-456 Project: C++ Standard Library Issue Type: Bug Components: External Environment: Intel Thread Checker 3.1 with Intel C++ 9.1 on Red Hat Enterprise Linux AS release 4 (Nahant Update 4) Reporter: Martin Sebor The thread checker gets into an infinite loop when running the 22.locale.time.put.mt test: tcheck_cl -v && make 22.locale.time.put.mt && time tcheck_cl -f html -o 22.locale.time.put.mt ./22.locale.time.put.mt --nthreads=2 --nloops=1 Intel(R) Thread Checker 3.1 command line instrumentation driver (24400) Copyright (c) 2007 Intel Corporation. All rights reserved. icc -cxxlib-nostd -g -w1 -I/amd/devco/sebor/stdcxx/include/ansi -D_RWSTDDEBUG -D_REENTRANT -I/amd/devco/sebor/stdcxx/include -I/build/sebor/stdcxx-icc-9.1_049-15S/include -I/amd/devco/sebor/stdcxx/tests/include -L/build/sebor/stdcxx-icc-9.1_049-15S/rwtest -lrwtest15S -cxxlib-nostd -lpthread -L/build/sebor/stdcxx-icc-9.1_049-15S/lib /amd/devco/sebor/stdcxx/tests/localization/22.locale.time.put.mt.cpp /build/sebor/stdcxx-icc-9.1_049-15S/lib/libstd15S.a /build/sebor/stdcxx-icc-9.1_049-15S/rwtest/librwtest15S.a -lstd15S -lcxaguard -lsupc++ -lm -o 22.locale.time.put.mt Intel(R) Thread Checker 3.1 command line instrumentation driver (24400) Copyright (c) 2007 Intel Corporation. All rights reserved. Building project Instrumenting 11% 22.locale.time.put.mt ( All Functions ):... . Running: /build/sebor/stdcxx-icc-9.1_049-15S/tests/22.locale.time.put.mt --nthreads=2 --nloops=1 # INFO (S1) (10 lines): # TEXT: # COMPILER: Intel C++, __INTEL_COMPILER = 910, __INTEL_COMPILER_BUILD_DATE = 20070320, __EDG_VERSION__ = 306 # ENVIRONMENT: x86_64/LP64 running linux-elf 2.4.20 with glibc 2.3 # FILE: 22.locale.time.put.mt.cpp # COMPILED: Jun 13 2007, 14:05:31 # COMMENT: thread safety # CLAUSE: lib.locale.time.put # NOTE (S2) (5 lines): # TEXT: executing "locale -a > /tmp/tmpfile-kF1e8S" # CLAUSE: lib.locale.time.put # FILE: process.cpp # LINE: 274 # INFO (S1) (3 lines): # TEXT: testing std::time_put with 2 threads, 1 iteration each, in locales { "aa_DJ" "aa_DJ.iso88591" "aa_DJ.utf8" "aa_ER" "[EMAIL PROTECTED]" "aa_ER.utf8" "[EMAIL PROTECTED]" "aa_ET" "aa_ET.utf8" "af_ZA" "af_ZA.iso88591" "af_ZA.utf8" "am_ET" "am_ET.utf8" "an_ES" "an_ES.iso885915" "an_ES.utf8" "ar_AE" "ar_AE.iso88596" "ar_AE.utf8" "ar_BH" "ar_BH.iso88596" "ar_BH.utf8" "ar_DZ" "ar_DZ.iso88596" "ar_DZ.utf8" "ar_EG" "ar_EG.iso88596" "ar_EG.utf8" "ar_IN" "ar_IN.utf8" "ar_IQ" } # CLAUSE: lib.locale.time.put # INFO (S1) (3 lines): # TEXT: exercising std::time_put # CLAUSE: lib.locale.time.put ^C Shutting down application. Please wait... Application finished real1m29.177s user1m2.169s sys 0m14.875s -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: STDCXX examples fails and reasons [MSVC]
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 21, 2007 8:56 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: STDCXX examples fails and reasons [MSVC] [...] > time_put like a bug in our infrastructure (I assume the > example assumes a certain time zone and it's being run in > another). The latter could (should?) be fixed by setting > the TZ environment variable time zone to the expected zone > before invoking this example. I have updated the windows build infrastructure to set TZ environment variable before run examples. The proposed similar changes in unix infrastructure below, but I'm not sure that is correct: Index: makefile.rules === --- makefile.rules (revision 549750) +++ makefile.rules (working copy) @@ -119,8 +119,9 @@ PATH=$$PATH:.; \ TOPDIR=$(TOPDIR); \ TMP=$${TMP:-/tmp}/stdcxx-run-; \ +TZ=MST+7; \ export TMP; \ -export LD_LIBRARY_PATH PATH TMP TOPDIR; \ +export LD_LIBRARY_PATH PATH TMP TOPDIR TZ; \ trap "rm -rf $$TMP" HUP INT QUIT TERM EXIT; \ mkdir -p $$TMP; \ ./run $(RUNFLAGS) $(RUNTARGET); \ @@ -133,8 +134,9 @@ PATH=$$PATH:$(LIBDIR):.; \ TOPDIR=$(TOPDIR); \ TMP=$${TMP:-/tmp}/stdcxx-run-; \ +TZ=MST+7; \ export TMP; \ -export LD_LIBRARY_PATH PATH TMP TOPDIR; \ +export LD_LIBRARY_PATH PATH TMP TOPDIR TZ; \ trap "rm -rf $$TMP" HUP INT QUIT TERM EXIT; \ mkdir -p $$TMP; \ ./run $(RUNFLAGS) $(RUNTARGET); \ Farid.
Re: Windows build error(s)
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 3:42 AM To: stdcxx-dev@incubator.apache.org Subject: Re: Windows build error(s) I've found how to handle this error here: http://msdn2.microsoft.com/en-us/library/ms228772(vs.80).aspx Unfortunately, jscript don't present the possibility to install COM message filter, so I've just perform the call in a loop with sleep: http://svn.apache.org/viewvc?view=rev&rev=548682 This looks like an infinite loop. It might fix the problem with the build but I worry that it could cause trouble under some other error conditions. The MSDN fix also looks quite different (not to mention much more complicated). Isn't there some middle ground between the two approaches? Yes. The both approaches performs retry the call. E.g., could we loop only a limited number of times and only when the error was caused by the timing issue discussed on the MSDN page (if we can reliably detect it)? Perhaps that will help: http://svn.apache.org/viewvc?view=rev&rev=549748 Unfortunately I can't check how this patch works. Okay, this makes me feel better. Thanks Martin
Re: svn commit: r549766 - in /incubator/stdcxx/trunk: examples/manual/rwexcept.cpp include/rw/_error.h src/exception.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 6:38 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r549766 - in /incubator/stdcxx/trunk: examples/manual/rwexcept.cpp include/rw/_error.h src/exception.cpp [...] From 7.1.2, p4: "If a function with external linkage is declared inline in one translation unit, it shall be declared inline in all translation units in which it appears; no diagnostic is required." Also, I think the convention used in the rest of the code is to put _RWSTD_EXPORT before the return type of the function, but you might want to double-check that. Either way, it should be consistent between the declaration and the definition of the function. Done: http://svn.apache.org/viewvc?view=rev&rev=549862 Sorry, this violates the last sentence of 3.2, p3: An inline function shall be defined in every translation unit in which it is used. Martin
RE: STDCXX examples fails and reasons [MSVC]
> -Original Message- > From: Farid Zaripov [mailto:[EMAIL PROTECTED] > Sent: Friday, June 22, 2007 7:30 PM > To: stdcxx-dev@incubator.apache.org > Subject: RE: STDCXX examples fails and reasons [MSVC] > > I have updated the windows build infrastructure to set TZ > environment variable before run examples. I've forget to specify the URL with changes: http://svn.apache.org/viewvc?view=rev&rev=549865 Farid.
RE: svn commit: r549766 - in /incubator/stdcxx/trunk: examples/manual/rwexcept.cpp include/rw/_error.h src/exception.cpp
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Friday, June 22, 2007 6:38 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r549766 - in > /incubator/stdcxx/trunk: examples/manual/rwexcept.cpp > include/rw/_error.h src/exception.cpp > [...] > From 7.1.2, p4: "If a function with external linkage is > declared inline in one translation unit, it shall be declared > inline in all translation units in which it appears; no > diagnostic is required." > > Also, I think the convention used in the rest of the code is > to put _RWSTD_EXPORT before the return type of the function, > but you might want to double-check that. Either way, it > should be consistent between the declaration and the > definition of the function. Done: http://svn.apache.org/viewvc?view=rev&rev=549862 Farid.
Re: svn commit: r549586 - /incubator/stdcxx/trunk/src/exception.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 6:07 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r549586 - /incubator/stdcxx/trunk/src/exception.cpp Yes, I remember that. This would be separated patch. Gotcha! Let's make sure to do that (or open a new issue). Already done: https://issues.apache.org/jira/browse/STDCXX-454 We can change the ChangeLog this way but it won't make the Jira Subversion plugin pick up the reference to the patch so the patch won't show up on the Subversion Commits tab. See https://issues.apache.org/jira/browse/INFRA-624 Now I understand. Btw why not to extend the JIRA interface to enable to add references to the svn manually? It would cetainly make a lot of sense. I added my vote to the open Jira issues that request this ability. You might want to do the same: http://jira.atlassian.com/browse/SVN-40 http://jira.atlassian.com/browse/SVN-138 Martin
Re: svn commit: r549766 - in /incubator/stdcxx/trunk: examples/manual/rwexcept.cpp include/rw/_error.h src/exception.cpp
[EMAIL PROTECTED] wrote: Author: faridz Date: Fri Jun 22 03:15:46 2007 New Revision: 549766 URL: http://svn.apache.org/viewvc?view=rev&rev=549766 [...] Modified: incubator/stdcxx/trunk/include/rw/_error.h URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/rw/_error.h?view=diff&rev=549766&r1=549765&r2=549766 == --- incubator/stdcxx/trunk/include/rw/_error.h (original) +++ incubator/stdcxx/trunk/include/rw/_error.h Fri Jun 22 03:15:46 2007 @@ -39,9 +39,12 @@ // (if any) used to format the exception object's what() string void _RWSTD_EXPORT __rw_throw (int, ...); +// frees memory buffer used for what() message +void _RWSTD_EXPORT __rw_free_what_buf (char*); ^ [...] Modified: incubator/stdcxx/trunk/src/exception.cpp URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/src/exception.cpp?view=diff&rev=549766&r1=549765&r2=549766 == --- incubator/stdcxx/trunk/src/exception.cpp (original) +++ incubator/stdcxx/trunk/src/exception.cpp Fri Jun 22 03:15:46 2007 @@ -438,10 +438,13 @@ static _RWSTD_THREAD int __rw_what_refcnt; -inline void __rw_free_what_buf (char* buf) +// free memory buffer allocated in __rw_vfmtwhat() +_RWSTD_EXPORT inline void __rw_free_what_buf (char* buf) From 7.1.2, p4: "If a function with external linkage is declared inline in one translation unit, it shall be declared inline in all translation units in which it appears; no diagnostic is required." Also, I think the convention used in the rest of the code is to put _RWSTD_EXPORT before the return type of the function, but you might want to double-check that. Either way, it should be consistent between the declaration and the definition of the function. Martin
RE: svn commit: r549586 - /incubator/stdcxx/trunk/src/exception.cpp
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Friday, June 22, 2007 6:07 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r549586 - > /incubator/stdcxx/trunk/src/exception.cpp > > Yes, I remember that. This would be separated patch. > > Gotcha! Let's make sure to do that (or open a new issue). Already done: https://issues.apache.org/jira/browse/STDCXX-454 > We can change the ChangeLog this way but it won't make the > Jira Subversion plugin pick up the reference to the patch so > the patch won't show up on the Subversion Commits tab. See > https://issues.apache.org/jira/browse/INFRA-624 Now I understand. Btw why not to extend the JIRA interface to enable to add references to the svn manually? Farid.
Re: STDCXX examples fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 8:56 PM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] [...] time_get looks like a bug (or lack of functionality) in our library time_get::date_order() returns time_get::do_date_order() which always returns dateorder () == no_order (loc/_time_get.h; line 137). Right. We ran out of time when implementing the facet. The standard doesn't require us to do any better so there hasn't been a lot of pressure to get back to it and finish the job, but that doesn't mean we should never do it. From a QoI point of view we definitely should. Also I observed that time_get::~time_get() should be protected (22.2.5.1), but in our library the time_get::~time_get() is not declared/defined. Yes, it is declared as protected in the standard to prevent standalone facet objects from being constructed. I'm not sure that's a detectable requirement. Violations of the requirement are detectable by non-conforming programs, but I can't think of a way how conformance to it could be detected -- can you? The same situation with ~time_get_byname(), ~time_put(), ~time_put_byname(). Our implementation lets users construct facet objects and use (at least some) them directly rather than going through the use_facet interface, which seems like a reasonable thing to do. Can you think of a reason not to keep this extension? Martin
Re: svn commit: r549586 - /incubator/stdcxx/trunk/src/exception.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 3:02 AM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r549586 - /incubator/stdcxx/trunk/src/exception.cpp As you astutely observed in a previous discussion of the issue (at the link below), "__rw_free_what_buf() should be extern _RWSTD_EXPORT, to be accessible by user in overridden __rw_throw_proc()" otherwise there will be no way for users to avoid a leak in their replacement __rw_throw_proc(). http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02192.htm l Yes, I remember that. This would be separated patch. Gotcha! Let's make sure to do that (or open a new issue). Also, while it's too late to fix it for this commit, the ChangeLog entry is missing a reference to the Jira issue number it resolves. Please remember to include it future changes, especially those to the library. The bug-fixing patch was here: http://svn.apache.org/viewvc?view=rev&rev=549584 Ah, okay. Anyway that patch is also related to the STDCXX-293, and is never late to correct the ChangeLog :) http://www.mail-archive.com/[EMAIL PROTECTED]/msg01322 .html We can change the ChangeLog this way but it won't make the Jira Subversion plugin pick up the reference to the patch so the patch won't show up on the Subversion Commits tab. See https://issues.apache.org/jira/browse/INFRA-624 Martin
Re: STDCXX examples fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 8:56 PM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] [...] limits.cpp should produce the qnan for Quiet NAN and snan for Signaling NAN on all platforms. I can't find this requirement in standard. It's not in the C++ standard but it is in C99, under fprintf(), the f and F conversion specifier: A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity — which style is implementation-defined. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) — which style, and the meaning of any n-char-sequence, is implementation-defined. The F conversion specifier produces INF, INFINITY, or NAN instead of inf, infinity, or nan, respectively. Martin
RE: STDCXX examples fails and reasons [MSVC]
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 21, 2007 8:56 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: STDCXX examples fails and reasons [MSVC] [...] > time_get looks like a bug (or lack of functionality) in our library time_get::date_order() returns time_get::do_date_order() which always returns dateorder () == no_order (loc/_time_get.h; line 137). Also I observed that time_get::~time_get() should be protected (22.2.5.1), but in our library the time_get::~time_get() is not declared/defined. The same situation with ~time_get_byname(), ~time_put(), ~time_put_byname(). Farid.
RE: STDCXX examples fails and reasons [MSVC]
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 21, 2007 8:56 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: STDCXX examples fails and reasons [MSVC] [...] > limits.cpp should produce the qnan for Quiet NAN and snan for > Signaling NAN on all platforms. I can't find this requirement in standard. The MSVC/Dinkumware STL produces: static double infinity () = 1.#INF; static double quiet_NaN () = 1.#QNAN; static double signaling_NaN () = 1.#QNAN; The gcc 3.4.4/SGI STL/Cygwin produces: static double infinity () = inf; static double quiet_NaN () = nan; static double signaling_NaN () = nan; Farid.
[jira] Commented: (STDCXX-455) [Cygwin] localedef errors: fatal error - could not load shell32, Win32 error 487
[ https://issues.apache.org/jira/browse/STDCXX-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507294 ] Farid Zaripov commented on STDCXX-455: -- Unable to debug this problem. Under strace or gdb all works fine. > [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.2 > > > 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] Resolved: (STDCXX-454) rwexcept example crashes due to using delete[] on static buffer
[ https://issues.apache.org/jira/browse/STDCXX-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-454. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewvc?view=rev&rev=549766 > rwexcept example crashes due to using delete[] on static buffer > --- > > Key: STDCXX-454 > URL: https://issues.apache.org/jira/browse/STDCXX-454 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2 > > > The rwexcept example crashes in function exception_handler() while performing > delete[] what. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-454) rwexcept example crashes due to using delete[] on static buffer
[ https://issues.apache.org/jira/browse/STDCXX-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-454. > rwexcept example crashes due to using delete[] on static buffer > --- > > Key: STDCXX-454 > URL: https://issues.apache.org/jira/browse/STDCXX-454 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2 > > > The rwexcept example crashes in function exception_handler() while performing > delete[] what. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-455) [Cygwin] localedef errors: fatal error - could not load shell32, Win32 error 487
[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.2 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] Closed: (STDCXX-353) [Cygwin] localedef errors: UCS value of symbolic character out of range
[ https://issues.apache.org/jira/browse/STDCXX-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-353. Resolution: Cannot Reproduce The new issue about locales: http://issues.apache.org/jira/browse/STDCXX-455 > [Cygwin] localedef errors: UCS value of symbolic character out of range > --- > > Key: STDCXX-353 > URL: https://issues.apache.org/jira/browse/STDCXX-353 > Project: C++ Standard Library > Issue Type: Bug > Components: Locales >Affects Versions: 4.1.3 > Environment: Cygwin >Reporter: Mark Brown >Assignee: Farid Zaripov > > On Cygwin, locale successfully builds all locales except zh_CN.GB18030 and > zh_TW.EUC-TW: > $ nice make -C../bin locales -k > make: Entering directory `/home/mbrown/stdcxx-gcc-4.1.1-15s/bin' > ./localedef -w -c -f /home/mbrown/stdcxx/etc/nls/charmaps/GB18030 -i > /home/mbrown/stdcxx/etc/nls/src/zh_CN > /home/mbrown/stdcxx-gcc-4.1.1-15s/nls/zh_CN.GB18030 > Error 315: UCS value 66304 of symbolic character out of range. > make: *** [zh_CN.GB18030] Error 4 > ./localedef -w -c -f /home/mbrown/stdcxx/etc/nls/charmaps/EUC-TW -i > /home/mbrown/stdcxx/etc/nls/src/zh_TW > /home/mbrown/stdcxx-gcc-4.1.1-15s/nls/zh_TW.EUC-TW > Error 315: UCS value 131083 of symbolic character out of range. > make: *** [zh_TW.EUC-TW] Error 4 > make: Target `locales' not remade because of errors. > make: Leaving directory `/home/mbrown/stdcxx-gcc-4.1.1-15s/bin' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-454) rwexcept example crashes due to using delete[] on static buffer
rwexcept example crashes due to using delete[] on static buffer --- Key: STDCXX-454 URL: https://issues.apache.org/jira/browse/STDCXX-454 Project: C++ Standard Library Issue Type: Bug Components: Examples Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2 The rwexcept example crashes in function exception_handler() while performing delete[] what. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Windows build error(s)
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Friday, June 22, 2007 3:42 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: Windows build error(s) > > > I've found how to handle this error here: > > http://msdn2.microsoft.com/en-us/library/ms228772(vs.80).aspx > > > > Unfortunately, jscript don't present the possibility to > install COM > > message filter, so I've just perform the call in a loop with sleep: > > http://svn.apache.org/viewvc?view=rev&rev=548682 > > This looks like an infinite loop. It might fix the problem > with the build but I worry that it could cause trouble under > some other error conditions. > The MSDN fix also looks quite different (not to mention much more > complicated). Isn't there some middle ground between the two approaches? Yes. The both approaches performs retry the call. > E.g., could we loop only a limited number of times and only when the error > was caused by the timing issue discussed on the MSDN page (if > we can reliably detect it)? Perhaps that will help: http://svn.apache.org/viewvc?view=rev&rev=549748 Unfortunately I can't check how this patch works. Farid.
Re: STDCXX progress to graduation
On 6/21/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: What effect do you believe GPLv3 will have, now that the FSF is acknowledging that GPL projects may freely take advantage of Apache Licensed code? If any, it might spur some people who would have considered libstdc++ to now look at what we have to offer. > things are as quiet as expected for a mature implementation of > a reference standard. Any concern that because of the maturity, it could stagnate and lose community? I think the community, as-is, can manage itself for now. If it proves incapable of managing itself later, then we deal with it - that said, I'm not overly concerned. Admittedly, it's not likely to go gangbusters (c.f. Harmony) - but I believe stdcxx is a nice, small, healthy little community doing what the committers are interested in - producing a world-class STL implementation under the ALv2 with our community principles behind it. -- justin
RE: svn commit: r549586 - /incubator/stdcxx/trunk/src/exception.cpp
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Friday, June 22, 2007 3:02 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r549586 - > /incubator/stdcxx/trunk/src/exception.cpp > > As you astutely observed in a previous discussion of the > issue (at the link below), "__rw_free_what_buf() should be > extern _RWSTD_EXPORT, to be accessible by user in overridden > __rw_throw_proc()" otherwise there will be no way for users > to avoid a leak in their replacement __rw_throw_proc(). > > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02192.htm l Yes, I remember that. This would be separated patch. > Also, while it's too late to fix it for this commit, the > ChangeLog entry is missing a reference to the Jira issue > number it resolves. > Please remember to include it future changes, especially > those to the library. The bug-fixing patch was here: http://svn.apache.org/viewvc?view=rev&rev=549584 Anyway that patch is also related to the STDCXX-293, and is never late to correct the ChangeLog :) http://www.mail-archive.com/[EMAIL PROTECTED]/msg01322 .html Farid.