Re: 4.2.0 build and test results
Andrew Black wrote: Greetings Martin I'm also seeing the same (mis)behavior. What you'll need to do is copy the .htaccess file from http://people.apache.org/~sebor/stdcxx/results/ to the http://people.apache.org/~sebor/stdcxx-4.2.0/results/ directory. Ah! I should have read INFRA-989 more carefully. It works now. Thanks! Martin --Andrew Black Martin Sebor wrote: With Andrew's help I've created a page with the build and test results of the stdcxx/4.2.0 branch to use as a baseline after the merge from trunk I'm planning to do later today: http://people.apache.org/~sebor/stdcxx-4.2.0/results/ Andrew, I'm having trouble opening the logs. Instead of opening them up in the browser it pops up the "What should SeaMonkey do with this file?" window. I know we (or was it just me?) had this problem before (https://issues.apache.org/jira/browse/INFRA-989) but I can open the new logs for trunk just fine. Any idea? Does it work for you? Martin
Re: 4.2.0 build and test results
Greetings Martin I'm also seeing the same (mis)behavior. What you'll need to do is copy the .htaccess file from http://people.apache.org/~sebor/stdcxx/results/ to the http://people.apache.org/~sebor/stdcxx-4.2.0/results/ directory. --Andrew Black Martin Sebor wrote: > With Andrew's help I've created a page with the build and test > results of the stdcxx/4.2.0 branch to use as a baseline after > the merge from trunk I'm planning to do later today: > > http://people.apache.org/~sebor/stdcxx-4.2.0/results/ > > Andrew, I'm having trouble opening the logs. Instead of opening > them up in the browser it pops up the "What should SeaMonkey do > with this file?" window. I know we (or was it just me?) had this > problem before (https://issues.apache.org/jira/browse/INFRA-989) > but I can open the new logs for trunk just fine. Any idea? Does > it work for you? > > Martin
Re: [jira] Closed: (STDCXX-462) std::time_get example exposes undefined behavior
Farid Zaripov (JIRA) wrote:
[
https://issues.apache.org/jira/browse/STDCXX-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-462.
FYI, this is a documentation bug. We need to change the code
on the Class Reference page as well:
http://incubator.apache.org/stdcxx/doc/stdlibref/time-get.html
It sure would be nice to figure out a way to automate these
updates between the example sources and the code in the docs.
A couple of possible approaches are here:
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03284.html
Any other ideas?
Martin
std::time_get example exposes undefined behavior
Key: STDCXX-462
URL: https://issues.apache.org/jira/browse/STDCXX-462
Project: C++ Standard Library
Issue Type: Bug
Components: Documentation
Affects Versions: 4.1.3, 4.1.2
Reporter: Martin Sebor
Assignee: Farid Zaripov
Priority: Critical
Fix For: 4.2
The example program demonstrating the use of the std::time_get facet
(http://incubator.apache.org/stdcxx/doc/stdlibref/time-get.html) exposes
undefined behavior. Quoting from the following post
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03760.html:
Martin Sebor wrote:
Farid Zaripov wrote:
[...]
Btw below is a part of the conforming program (taken from
time_get.cpp)?
It's not a conforming program. The locale must stay around as
long as the last reference to the facet obtained from it. The
tests that fail to follow this rule should be changed.
---
const std::time_get &tg =
std::use_facet >(std::locale ("C"));
// Display time_base::dateorder value.
std::cout << "time_base::dateorder == " << tg.date_order () <<
".\n";
---
This fragment fails on Dinkumware STL because of tg.date_order() uses
(internal)
pointer to the destroyed locale object.
Right, and that's allowed.
4.2.0 build and test results
With Andrew's help I've created a page with the build and test results of the stdcxx/4.2.0 branch to use as a baseline after the merge from trunk I'm planning to do later today: http://people.apache.org/~sebor/stdcxx-4.2.0/results/ Andrew, I'm having trouble opening the logs. Instead of opening them up in the browser it pops up the "What should SeaMonkey do with this file?" window. I know we (or was it just me?) had this problem before (https://issues.apache.org/jira/browse/INFRA-989) but I can open the new logs for trunk just fine. Any idea? Does it work for you? Martin
4.2.0 merge today
The test results look good on most platforms and I'd like to merge trunk to 4.2.0 today. If there are any objections let me know ASAP. The one problematic platform that might need some attention is Intel Intel C++ 9.1 on Windows 2000/x86. A 12d build fails with this error: Linking...(Intel C++ Environment) xilink: executing 'link' Creating library D:\bman5\builds\33762791\source-buildspace\build\icc-9.1\12d\lib\libstd12d.lib and object D:\bman5\builds\33762791\source-buildspace\build\icc-9.1\12d\lib\libstd12d.exp wctype.obj : fatal error LNK1103: debugging information corrupt; recompile module Here's the log: http://people.apache.org/~sebor/stdcxx/results/Windows_2000-icl-32b-9.1-12d-win32-log.gz.txt Farid, can you reproduce this in your environment? Martin
RE: STDCXX examples fails and reasons [MSVC]
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Monday, June 25, 2007 7:41 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: STDCXX examples fails and reasons [MSVC] > > >> 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? > > > > It would be difficult. :) > > Difficult is not impossible :) If you think it's possible we > have a conformance problem. Otherwise, if you don't believe > it's possible, we're fine. Ok, ok. It's impossible. ^) > > Btw below is a part of the conforming program (taken from > > time_get.cpp)? > > It's not a conforming program. The locale must stay around as > long as the last reference to the facet obtained from it. The > tests that fail to follow this rule should be changed. Done: http://svn.apache.org/viewvc?view=rev&rev=550774 Farid.
RE: STDCXX examples fails and reasons [MSVC]
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Friday, June 22, 2007 5:58 PM > To: stdcxx-dev@incubator.apache.org > Subject: 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. Ok, thanks. Could you share the C99 standard? Farid.
RE: status of thread safety tests
> -Original Message-
> From: Mark Brown [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 26, 2007 5:06 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: status of thread safety tests
>
> 22.locale.num.put.mt gets a SIGSEGV on my system (Fedora 6)
> even with a single thread. Here's the output of gdb:
The same trouble on MSVC. And I found the problem.
struct Ios: std::ios {
} io;
Here should be defined ctor invoking ios_base::init() according to
27.4.2.7 p1: Ios () { this->init (0); }
The same bug present in 22.locale.money.put.mt and
22.locale.time.put.mt tests.
Fixed thus: http://svn.apache.org/viewvc?view=rev&rev=550833
I'm not sure if this patch resolves the STDCXX-450 issue.
Farid.
Re: svn commit: r550545 - in /incubator/stdcxx/trunk/tests/localization: 22.locale.ctype.is.cpp 22.locale.ctype.narrow.cpp 22.locale.ctype.scan.cpp 22.locale.ctype.tolower.cpp 22.locale.ctype.toupper.
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 9:38 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r550545 - in /incubator/stdcxx/trunk/tests/localization: 22.locale.ctype.is.cpp 22.locale.ctype.narrow.cpp 22.locale.ctype.scan.cpp 22.locale.ctype.tolower.cpp 22.locale.ctype.toupper.cpp [EMAIL PROTECTED] wrote: Author: faridz Date: Mon Jun 25 09:50:10 2007 New Revision: 550545 Thanks for taking care of this! IIRC, you made a similar change before, suggesting the rw_locales() API is error-prone. I wonder if we should change it so as to return "" instead of 0 on error. Incidentally, why does it fail in your environment? When I run the test only, the locale.exe utility not in the path and then the rw_locales() returns NULL. And later when the test iterating through the list I got access violation. I aggree to change rw_locales() to return something but not NULL. Perhaps rw_locales() should return "C"? I assume that "C" locale is always available, isn't it? Yes, it is. That might make more sense than returning "". Actually, it will need to be "C\0", i.e., there must be two NULs at the end of the string. Martin
RE: svn commit: r550545 - in /incubator/stdcxx/trunk/tests/localization: 22.locale.ctype.is.cpp 22.locale.ctype.narrow.cpp 22.locale.ctype.scan.cpp 22.locale.ctype.tolower.cpp 22.locale.ctype.toupper.
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Monday, June 25, 2007 9:38 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r550545 - in > /incubator/stdcxx/trunk/tests/localization: > 22.locale.ctype.is.cpp 22.locale.ctype.narrow.cpp > 22.locale.ctype.scan.cpp 22.locale.ctype.tolower.cpp > 22.locale.ctype.toupper.cpp > > [EMAIL PROTECTED] wrote: > > Author: faridz > > Date: Mon Jun 25 09:50:10 2007 > > New Revision: 550545 > > Thanks for taking care of this! IIRC, you made a similar > change before, suggesting the rw_locales() API is > error-prone. I wonder if we should change it so as to return > "" instead of 0 on error. > > Incidentally, why does it fail in your environment? When I run the test only, the locale.exe utility not in the path and then the rw_locales() returns NULL. And later when the test iterating through the list I got access violation. I aggree to change rw_locales() to return something but not NULL. Perhaps rw_locales() should return "C"? I assume that "C" locale is always available, isn't it? Farid.
RE: list of available cross-build result views
> -Original Message- > From: [EMAIL PROTECTED] > Sent: Sat, 16 Jun 2007 15:59:11 -0600 > To: stdcxx-dev@incubator.apache.org > Subject: list of available cross-build result views > > ...is on the page below. This page and the cross-build views are > all set up to get generated from the all-platform build result > data at 8AM PDT every day. > >http://people.apache.org/~sebor/stdcxx/results/builds.html Martin, This looks interesting. I have a question though. There are a number of black cells in the test tables on most of the pages. For instance, the 22.locale.num.put.mt test on the redhat_as-5.0-em64t-gcc-4.1.1.html page. Does it mean the test did not run? I looked for the test on the redhat_as-5.0-em64t-gcc-64b-4.1.1-12d-log.gz.txt page referenced from column 12 (the closest I could find to 15D). The status of the test is SEGV but when I looked in the log I couldn't find the test there. -- Mark
crash in 22.locale.num.put.mt (was RE: status of thread safety tests)
It might be more helpful if I include the debugging information. The test runs
okay with just one thread in a debug build so this output is for two threads.
(gdb) r --nthreads=2
Starting program: /home/mbrown/stdcxx-gcc-4.1.1-15D/tests/22.locale.num.put.mt
--nthreads=2
[Thread debugging using libthread_db enabled]
[New Thread 46912499588704 (LWP 23444)]
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: gcc 4.1.1, __VERSION__ = "4.1.1 20070105 (Red Hat 4.1.1-51)"
# ENVIRONMENT: amd64/LP64 running linux-elf (unknown release) with glibc 2.5
# FILE: 22.locale.num.put.mt.cpp
# COMPILED: Jun 26 2007, 08:08:46
# COMMENT: thread safety
# CLAUSE: lib.locale.num.put
# NOTE (S2) (5 lines):
# TEXT: executing "locale -a > /tmp/tmpfile-6SA0KQ"
# CLAUSE: lib.locale.num.put
# FILE: process.cpp
# LINE: 274
# INFO (S1) (3 lines):
# TEXT: testing std::num_put with 2 threads, 20 iterations 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.num.put
# INFO (S1) (3 lines):
# TEXT: exercising std::num_put
# CLAUSE: lib.locale.num.put
[New Thread 1084229952 (LWP 23447)]
[New Thread 1094719808 (LWP 23448)]
*** glibc detected ***
/home/mbrown/stdcxx-gcc-4.1.1-15D/tests/22.locale.num.put.mt: double free or
corruption (fasttop): 0x00649720 ***
=== Backtrace: =
/lib64/libc.so.6[0x39f826ea30]
/lib64/libc.so.6(cfree+0x8c)[0x39f827214c]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZN4__rw15__rw_deallocateEPvmi+0x1c)[0x2ab18a9e]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNSaIcE10deallocateEPcm+0x26)[0x2ab29626]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNSs9_C_unlinkEPc+0xb6)[0x2ab296de]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNSsD1Ev+0x1a)[0x2ab2ec86]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6_C_putES3_RSt8ios_baseciPKv+0x6b2)[0x2ab35448]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecl+0x3d)[0x2ab3564b]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE3putES3_RSt8ios_basecl+0x43)[0x2ab26c07]
/home/mbrown/stdcxx-gcc-4.1.1-15D/tests/22.locale.num.put.mt[0x405091]
/lib64/libpthread.so.0[0x39fae06305]
/lib64/libc.so.6(clone+0x6d)[0x39f82cd50d]
=== Memory map:
0040-0042c000 r-xp 08:02 22086788
/home/mbrown/stdcxx-gcc-4.1.1-15D/tests/22.locale.num.put.mt
0062c000-0062e000 rw-p 0002c000 08:02 22086788
/home/mbrown/stdcxx-gcc-4.1.1-15D/tests/22.locale.num.put.mt
0062e000-00651000 rw-p 0062e000 00:00 0 [heap]
4000-40001000 ---p 4000 00:00 0
40001000-40a01000 rwxp 40001000 00:00 0
40a01000-40a02000 ---p 40a01000 00:00 0
40a02000-41402000 rwxp 40a02000 00:00 0
39f700-39f701a000 r-xp 08:02 17006594
/lib64/ld-2.5.so
39f7219000-39f721a000 r--p 00019000 08:02 17006594
/lib64/ld-2.5.so
39f721a000-39f721b000 rw-p 0001a000 08:02 17006594
/lib64/ld-2.5.so
39f820-39f8344000 r-xp 08:02 17006597
/lib64/libc-2.5.so
39f8344000-39f8544000 ---p 00144000 08:02 17006597
/lib64/libc-2.5.so
39f8544000-39f8548000 r--p 00144000 08:02 17006597
/lib64/libc-2.5.so
39f8548000-39f8549000 rw-p 00148000 08:02 17006597
/lib64/libc-2.5.so
39f8549000-39f854e000 rw-p 39f8549000 00:00 0
39f860-39f8682000 r-xp 08:02 17006804
/lib64/libm-2.5.so
39f8682000-39f8881000 ---p 00082000 08:02 17006804
/lib64/libm-2.5.so
39f8881000-39f8882000 r--p 00081000 08:02 17006804
/lib64/libm-2.5.so
39f8882000-39f8883000 rw-p 00082000 08:02 17006804
/lib64/libm-2.5.so
39fae0-39fae15000 r-xp 08:02 17006792
/lib64/libpthread-2.5.so
39fae15000-39fb014000 ---p 00015000 08:02 17006792
/lib64/libpthread-2.5.so
39fb014000-39fb015000 r--p 00014000 08:02 17006792
/lib64/libpthread-2.5.so
39fb015000-39fb016000 rw-p 00015000 08:02 17006792
/lib64/libpthread-2.5.so
39fb016000-39fb01a000 rw-p 39fb016000 00:00 0
3a0500-3a0500d000 r-xp 08:02 17006751
/lib64/libgcc_s-4.1.1-20070105.so.1
3a0500d000-3a0520c
RE: status of thread safety tests
22.locale.num.put.mt gets a SIGSEGV on my system (Fedora 6) even with a single
thread. Here's the output of gdb:
$ gdb ./22.locale.num.put.mt
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) run --nthreads=1
Starting program: /home/mbrown/stdcxx-gcc-4.1.1-12D/tests/22.locale.num.put.mt -
-nthreads=1
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 46912499232352 (LWP 32189)]
(no debugging symbols found)
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: gcc 4.1.1, __VERSION__ = "4.1.1 20070105 (Red Hat 4.1.1-51)"
# ENVIRONMENT: amd64/LP64 running linux-elf (unknown release) with glibc 2.5
# FILE: 22.locale.num.put.mt.cpp
# COMPILED: Jun 26 2007, 07:52:50
# COMMENT: thread safety
# CLAUSE: lib.locale.num.put
# NOTE (S2) (5 lines):
# TEXT: executing "locale -a > /tmp/tmpfile-st2gNr"
# CLAUSE: lib.locale.num.put
# FILE: process.cpp
# LINE: 274
# INFO (S1) (3 lines):
# TEXT: testing std::num_put with 1 thread, 20 iterations each, in lo
cales { "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.iso885
96" "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.num.put
# INFO (S1) (3 lines):
# TEXT: exercising std::num_put
# CLAUSE: lib.locale.num.put
[New Thread 1084229952 (LWP 32194)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1084229952 (LWP 32194)]
0x2aafb027 in std::locale::locale ()
from /home/mbrown/stdcxx-gcc-4.1.1-12D/lib/libstd12D.so
(gdb) where
#0 0x2aafb027 in std::locale::locale ()
from /home/mbrown/stdcxx-gcc-4.1.1-12D/lib/libstd12D.so
#1 0x00403eea in thread_func ()
#2 0x0039fae06305 in start_thread () from /lib64/libpthread.so.0
#3 0x0039f82cd50d in clone () from /lib64/libc.so.6
#4 0x in ?? ()
-- Mark
> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Mon, 18 Jun 2007 21:20:27 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: status of thread safety tests
>
> I've been working on a document listing the thread safety tests
> in stdcxx/trunk and their current status:
>
>http://people.apache.org/~sebor/thread_safety_tests.html
>
> The goal is to have a full understanding of all the problems
> and address them (or at least the most important ones) in the
> final 4.2.0 release.
>
> The document is still a work in progress, as is the test suite.
> Not all tests have been migrated from the Rogue Wave test suite
> in Perforce over to ASF Subversion. For those tests the links
> that point to the Perforce source repository won't work.
[jira] Closed: (STDCXX-462) std::time_get example exposes undefined behavior
[
https://issues.apache.org/jira/browse/STDCXX-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov closed STDCXX-462.
> std::time_get example exposes undefined behavior
>
>
> Key: STDCXX-462
> URL: https://issues.apache.org/jira/browse/STDCXX-462
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 4.1.3, 4.1.2
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Critical
> Fix For: 4.2
>
>
> The example program demonstrating the use of the std::time_get facet
> (http://incubator.apache.org/stdcxx/doc/stdlibref/time-get.html) exposes
> undefined behavior. Quoting from the following post
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03760.html:
> Martin Sebor wrote:
> > Farid Zaripov wrote:
> [...]
> >> Btw below is a part of the conforming program (taken from
> >> time_get.cpp)?
> >
> > It's not a conforming program. The locale must stay around as
> > long as the last reference to the facet obtained from it. The
> > tests that fail to follow this rule should be changed.
> >
> >>
> >> ---
> >> const std::time_get &tg =
> >> std::use_facet >(std::locale ("C"));
> >>
> >> // Display time_base::dateorder value.
> >> std::cout << "time_base::dateorder == " << tg.date_order () <<
> >> ".\n";
> >> ---
> >>
> >> This fragment fails on Dinkumware STL because of tg.date_order() uses
> >> (internal)
> >> pointer to the destroyed locale object.
> >
> > Right, and that's allowed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-462) std::time_get example exposes undefined behavior
[
https://issues.apache.org/jira/browse/STDCXX-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-462.
--
Resolution: Fixed
Fix Version/s: 4.2
Fixed thus: http://svn.apache.org/viewvc?view=rev&rev=550774
> std::time_get example exposes undefined behavior
>
>
> Key: STDCXX-462
> URL: https://issues.apache.org/jira/browse/STDCXX-462
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 4.1.3, 4.1.2
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Critical
> Fix For: 4.2
>
>
> The example program demonstrating the use of the std::time_get facet
> (http://incubator.apache.org/stdcxx/doc/stdlibref/time-get.html) exposes
> undefined behavior. Quoting from the following post
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03760.html:
> Martin Sebor wrote:
> > Farid Zaripov wrote:
> [...]
> >> Btw below is a part of the conforming program (taken from
> >> time_get.cpp)?
> >
> > It's not a conforming program. The locale must stay around as
> > long as the last reference to the facet obtained from it. The
> > tests that fail to follow this rule should be changed.
> >
> >>
> >> ---
> >> const std::time_get &tg =
> >> std::use_facet >(std::locale ("C"));
> >>
> >> // Display time_base::dateorder value.
> >> std::cout << "time_base::dateorder == " << tg.date_order () <<
> >> ".\n";
> >> ---
> >>
> >> This fragment fails on Dinkumware STL because of tg.date_order() uses
> >> (internal)
> >> pointer to the destroyed locale object.
> >
> > Right, and that's allowed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-462) std::time_get example exposes undefined behavior
[
https://issues.apache.org/jira/browse/STDCXX-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-462:
Assignee: Farid Zaripov
> std::time_get example exposes undefined behavior
>
>
> Key: STDCXX-462
> URL: https://issues.apache.org/jira/browse/STDCXX-462
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 4.1.3, 4.1.2
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Critical
>
> The example program demonstrating the use of the std::time_get facet
> (http://incubator.apache.org/stdcxx/doc/stdlibref/time-get.html) exposes
> undefined behavior. Quoting from the following post
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03760.html:
> Martin Sebor wrote:
> > Farid Zaripov wrote:
> [...]
> >> Btw below is a part of the conforming program (taken from
> >> time_get.cpp)?
> >
> > It's not a conforming program. The locale must stay around as
> > long as the last reference to the facet obtained from it. The
> > tests that fail to follow this rule should be changed.
> >
> >>
> >> ---
> >> const std::time_get &tg =
> >> std::use_facet >(std::locale ("C"));
> >>
> >> // Display time_base::dateorder value.
> >> std::cout << "time_base::dateorder == " << tg.date_order () <<
> >> ".\n";
> >> ---
> >>
> >> This fragment fails on Dinkumware STL because of tg.date_order() uses
> >> (internal)
> >> pointer to the destroyed locale object.
> >
> > Right, and that's allowed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: Convert MSVC CRT debug reports to rwtest driver debug reports
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 26, 2007 1:31 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: Convert MSVC CRT debug reports to rwtest driver > debug reports > > Farid Zaripov wrote: > > In some tests in debug mode GUI popups appear. > > We can disable this popups by using _CrtSetReportMode(, > > _CRTDBG_MODE_DEBUG), but I think it would be useful to convert them > > into the rwtest debug reports (rw_warn(), rw_error(), rw_assert()). > > This conversion can be made by installing custom hook function. > > Sounds reasonable, but I'd like to know a little bit more > about what types of errors we're dealing with here. > > Which of the three types of diagnostics does your patch > convert them to? I think rw_error() would be appropriate for > undefined behavior like memory corruption detected by the > CRT, etc. What other types of errors cause these popups? The MSVC CRT has three types of report: _CRT_WARN, _CRT_ERROR, and _CRT_ASSERT. #define _CRT_WARN 0 #define _CRT_ERROR 1 #define _CRT_ASSERT 2 These types mapped to rw_warn(), rw_error() and rw_assert() respectively. > > And also MSVC8 CRT performs parameter checking with invoking > > Dr.Watson tool (the result is GUI > > popup) in case the invalid parameter was passed to the CRT > function. I > > suggest to convert this popups to the rw_note() reports (or maybe > > rw_error()). > > In terms of the severity, rw_note() is quite different from > rw_error(), so it's important to understand what types of > errors we're dealing with. Can you give more detail about > these invalid parameter errors, or a few examples? For example in test 21.cwchar.cpp line 934 the wcsftime() invoked with the parameter size == 0. Actually zero value is valid for that function, but MSVC CRT performs validation to size != 0 and issues Dr.Watson popup. Because of that we can't convert invalid parameter errors to rw_error() even if in some other case the checked parameter would be invalid. Farid.
