Re: svn commit: r555970 - /incubator/stdcxx/trunk/tests/src/fmt_bits.cpp
[EMAIL PROTECTED] wrote: Author: faridz Date: Fri Jul 13 05:31:08 2007 New Revision: 555970 URL: http://svn.apache.org/viewvc?view=revrev=555970 Log: 2007-07-13 Farid Zaripov [EMAIL PROTECTED] * fmt_bits.cpp (_rw_fmtlasterror): Cast pmsg to const char* to avoid MSVC error. Thanks and sorry for the berakage! My bad for not testing the change. I should know better than that. (I did a build but forgot to check the result -- not a very useful thing to do.) Martin Modified: incubator/stdcxx/trunk/tests/src/fmt_bits.cpp Modified: incubator/stdcxx/trunk/tests/src/fmt_bits.cpp URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/tests/src/fmt_bits.cpp?view=diffrev=555970r1=555969r2=555970 == --- incubator/stdcxx/trunk/tests/src/fmt_bits.cpp (original) +++ incubator/stdcxx/trunk/tests/src/fmt_bits.cpp Fri Jul 13 05:31:08 2007 @@ -1026,7 +1026,9 @@ newspec.width= 0; newspec.fl_pound = 0; -const int result = _rw_fmtstr (newspec, buf, pmsg, _RWSTD_SIZE_MAX); +const int result = _rw_fmtstr (newspec, buf, + _RWSTD_STATIC_CAST (const char*, pmsg), + _RWSTD_SIZE_MAX); LocalFree (pmsg);
Re: svn commit: r555006 - /incubator/stdcxx/trunk/src/catalog.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 11, 2007 10:14 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r555006 - /incubator/stdcxx/trunk/src/catalog.cpp * catalog.cpp (catopen): while() loop replaced to for() loop with checking for max iterations. Does this fix a bug? Definitely :) As you can see the __rw_catlist container resized only if i == __rw_catlist.size(), but before of that __rw_catlist.size()'th element is accessed in while (__rw_catlist[i] != 0) and this is undefined behavior. If it does, is the bug easily reproducible so we can add a test case for it to the bug tracking database? For the test case the valid catalog should be created (.dll file on windows). It's not so easy and platform dependent. Of course we can use generate_catalog () function from 22.locale.messages.cpp test. That seems like a good approach. We could use it as the first step toward providing an easier and portable way to build message catalogs on Windows as well as other platforms. A portable utility that takes a source file such as rwstderr.msg or rwstderr.rc as input and produces a catalog from it suitable for the target platform. Martin
Re: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 11, 2007 10:25 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp [EMAIL PROTECTED] wrote: Author: faridz Date: Thu Jul 5 11:13:04 2007 New Revision: 553587 URL: http://svn.apache.org/viewvc?view=revrev=553587 Log: 2007-07-05 Farid Zaripov [EMAIL PROTECTED] * 0.new.cpp: Catch SIGSEGV signal as SIGABRT. Why is this necessary? On MSVC operator delete[] () invoke operator delete (). So in the following code (taken from test_mismatch()): void* p = operator new (0); operator delete[] (p); operator delete (p); the operator delete[] (p) frees the memory and next operator delete (p) raises SIGSEGV. To continue the execution and check another testcases the SIGSEGV signal should be handled. But the SIGSEGV indicates an error, while SIGABRT indicates the expected behavior. I.e., the replacement operator delete defined in the driver aborts when it's passed a pointer that wasn't returned from a prior call to the matching operator new. The operator should never segfault. Is the replacement operator not being called? Martin
Re: [VOTE] ready to graduate
Eric Lemings wrote: -1! Nah, I'm just kidding. +1. Seriously though, did you really expect to get any dissenting votes from anyone on the stdcxx-dev mailing list? :P Thanks for the +1. The vote is important because it formally establishes a record of a consensus within our community for those who aren't on the list, such as the Incubator PMC and the Board. Martin Eric. -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Thursday, July 05, 2007 3:14 PM To: stdcxx-dev@incubator.apache.org Subject: [VOTE] ready to graduate Our mentors as well as a number of IPMC members recently expressed confidence in stdcxx being ready to graduate out of the incubator (see the thread starting with msg14476 below). In order to propose graduation to the Incubator PMC we all need to formally agree that we are ready. This is a vote to ascertain this agreement. [ ] Check here (or use +1) to indicate you agree that stdcxx is ready to graduate. [ ] Check here (or use -1) to indicate that stdcxx is not ready to graduate at this point. If you check this please provide comments explaining what you feel needs to change in order for it to become ready. Martin http://www.mail-archive.com/[EMAIL PROTECTED]/msg14476.html
Re: FW: Built STDCXX On Mac Lately?
I don't think it's a problem in your environment. STDCXX-404 describes the same issue on FreeBSD. We still need to look into it: http://issues.apache.org/jira/browse/STDCXX-404 If you could add your comments to this issue or file a new one that would be great. Martin Eric Lemings wrote: For everyone else's viewing pleasure: From: Eric Lemings Sent: Thursday, July 12, 2007 6:30 PM To: Andrew Black Cc: Martin Sebor Subject: Built STDCXX On Mac Lately? Has anyone built STDCXX on Mac lately? I just tried and got some compile errors in util/localedef.cpp. At first glance, it looks like the change that conditionally includes iconv.h is the culprit. There are still symbols from that header file still being used in the source file even when the header is not included. Here's the error: gcc runall.o cmdopt.o output.o util.o exec.o display.o -o exec -L/Users/elemings/Developer/Build/stdcxx/lib -lstd -lsupc++ -lgcc_eh -lm gcc -c -I/Users/elemings/Developer/Work/stdcxx/include/ansi -D_RWSTDDEBUG-I/Users/elemings/Developer/Work/stdcxx/include -I/Users/elemings/Developer/Build/stdcxx/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /Users/elemings/Developer/Work/stdcxx/util/localedef.cpp In file included from /Users/elemings/Developer/Work/stdcxx/util/def.h:45, from /Users/elemings/Developer/Work/stdcxx/util/localedef.cpp:30: /Users/elemings/Developer/Work/stdcxx/util/charmap.h:167: error: 'iconv_t' does not name a type /Users/elemings/Developer/Work/stdcxx/util/charmap.h:230: error: 'iconv_t' does not name a type /Users/elemings/Developer/Work/stdcxx/util/charmap.h:233: error: 'iconv_t' does not name a type /Users/elemings/Developer/Work/stdcxx/util/localedef.cpp: In function 'bool process_command_line(ProgramOptions*, int, char**)': /Users/elemings/Developer/Work/stdcxx/util/localedef.cpp:475: warning: unused variable 'errors' make[2]: *** [localedef.o] Error 1 make[1]: *** [util] Error 2 make: *** [libstd] Error 2 I was about to file a Jira issue but thought I'd make sure this is really an error and not my environment. Brad.
[jira] Commented: (STDCXX-404) [FreeBSD 6.2] error on iconv.h in locale utilities
[ https://issues.apache.org/jira/browse/STDCXX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512594 ] Eric Lemings commented on STDCXX-404: - The same error occurs when building STDCXX on Mac OS X 10.4.10 (Tiger) with GCC 4.2. ... gcc runall.o cmdopt.o output.o util.o exec.o display.o -o exec -L/stdcxx/lib -lstd -lsupc++ -lgcc_eh -lm gcc -c -I/stdcxx/include/ansi -D_RWSTDDEBUG-I/stdcxx/include -I/stdcxx/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /stdcxx/util/localedef.cpp In file included from /stdcxx/util/def.h:45, from /stdcxx/util/localedef.cpp:30: /stdcxx/util/charmap.h:167: error: 'iconv_t' does not name a type /stdcxx/util/charmap.h:230: error: 'iconv_t' does not name a type /stdcxx/util/charmap.h:233: error: 'iconv_t' does not name a type /stdcxx/util/localedef.cpp: In function 'bool process_command_line(ProgramOptions*, int, char**)': /stdcxx/util/localedef.cpp:475: warning: unused variable 'errors' make[2]: *** [localedef.o] Error 1 make[1]: *** [util] Error 2 make: *** [libstd] Error 2 [FreeBSD 6.2] error on iconv.h in locale utilities Key: STDCXX-404 URL: https://issues.apache.org/jira/browse/STDCXX-404 Project: C++ Standard Library Issue Type: Bug Components: Utilities Affects Versions: 4.2 Environment: gcc 3.4.6/FreeBSD/x86 Reporter: Martin Sebor Priority: Critical Fix For: 4.2 The locale utilities locale and localedef fail to build on FreeBSD due to assumptions about the iconv.h header which apparently isn't provided on this platform: gcc -c -I$(TOPDIR)/include/ansi -D_RWSTDDEBUG-I$(TOPDIR)/include -I$(BUILDDIR)/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align $(TOPDIR)/util/localedef.cpp In file included from $(TOPDIR)/util/def.h:45, from $(TOPDIR)/util/localedef.cpp:30: $(TOPDIR)/util/charmap.h:39:21: iconv.h: No such file or directory In file included from $(TOPDIR)/util/def.h:45, from $(TOPDIR)/util/localedef.cpp:30: $(TOPDIR)/util/charmap.h:165: error: `iconv_t' does not name a type $(TOPDIR)/util/charmap.h:165: error: extra semicolon $(TOPDIR)/util/charmap.h:228: error: `iconv_t' does not name a type $(TOPDIR)/util/charmap.h:228: error: extra semicolon $(TOPDIR)/util/charmap.h:231: error: `iconv_t' does not name a type $(TOPDIR)/util/charmap.h:231: error: extra semicolon $(TOPDIR)/util/localedef.cpp: In function `bool process_command_line(ProgramOptions*, int, char**)': $(TOPDIR)/util/localedef.cpp:475: warning: unused variable 'errors' gmake: *** [localedef.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-404) [FreeBSD 6.2] error on iconv.h in locale utilities
[ https://issues.apache.org/jira/browse/STDCXX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Lemings updated STDCXX-404: Environment: gcc 3.4.6/FreeBSD/x86 gcc 4.2/Mac OS X 10.4.10 (Tiger) was:gcc 3.4.6/FreeBSD/x86 [FreeBSD 6.2] error on iconv.h in locale utilities Key: STDCXX-404 URL: https://issues.apache.org/jira/browse/STDCXX-404 Project: C++ Standard Library Issue Type: Bug Components: Utilities Affects Versions: 4.2 Environment: gcc 3.4.6/FreeBSD/x86 gcc 4.2/Mac OS X 10.4.10 (Tiger) Reporter: Martin Sebor Priority: Critical Fix For: 4.2 The locale utilities locale and localedef fail to build on FreeBSD due to assumptions about the iconv.h header which apparently isn't provided on this platform: gcc -c -I$(TOPDIR)/include/ansi -D_RWSTDDEBUG-I$(TOPDIR)/include -I$(BUILDDIR)/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align $(TOPDIR)/util/localedef.cpp In file included from $(TOPDIR)/util/def.h:45, from $(TOPDIR)/util/localedef.cpp:30: $(TOPDIR)/util/charmap.h:39:21: iconv.h: No such file or directory In file included from $(TOPDIR)/util/def.h:45, from $(TOPDIR)/util/localedef.cpp:30: $(TOPDIR)/util/charmap.h:165: error: `iconv_t' does not name a type $(TOPDIR)/util/charmap.h:165: error: extra semicolon $(TOPDIR)/util/charmap.h:228: error: `iconv_t' does not name a type $(TOPDIR)/util/charmap.h:228: error: extra semicolon $(TOPDIR)/util/charmap.h:231: error: `iconv_t' does not name a type $(TOPDIR)/util/charmap.h:231: error: extra semicolon $(TOPDIR)/util/localedef.cpp: In function `bool process_command_line(ProgramOptions*, int, char**)': $(TOPDIR)/util/localedef.cpp:475: warning: unused variable 'errors' gmake: *** [localedef.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-484) [HP aCC 3.74] -E +Maked ICE on a conditional with new
[ https://issues.apache.org/jira/browse/STDCXX-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512601 ] Martin Sebor commented on STDCXX-484: - The test case can be simplified even further: $ cat t.cpp aCC +Maked -E -V t.cpp void foo (int i) { i 0 ? 0 : new int; } aCC: HP ANSI C++ B3910B A.03.74 Signal 11 ( 0) 0x00298924 sighandler__FiT1 + 0x134 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 1) 0xc022c328 _sigreturn [/usr/lib/libc.2] ( 2) 0x0026b76c synthesize__15LibraryRoutinesF19LibraryRoutinesEnum + 0x7c [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 3) 0x0026f7dc enter__15LibraryRoutinesF19LibraryRoutinesEnum + 0x10 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 4) 0x001ca0d8 lookup__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicListXTP4 + 0x168 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 5) 0x001c9e84 find__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicListXTP4No + 0x9c [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 6) 0x001a1e64 hasPointerToMemberComing__12PreprocessorFQ2_12Preprocessor8PTMStateP11Declaratio + 0x844 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 7) 0x002375f4 isProbablyAnIdentifier__12PreprocessorFb + 0x54 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 8) 0x001c7b7c resolveIdentifier__12PreprocessorFP12ScannerValue11StringToken + 0xbd4 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 9) 0x001c5a30 nextToken__12PreprocessorFP12ScannerValue + 0x210 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] (10) 0x0026adc4 DoCompile__8CompilerFv + 0xd44 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] (11) 0x000b347c DoCompile__8CompilerFP6Buffer + 0x34 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] (12) 0x000b9178 DoCompileFile__8CompilerFPc + 0x110 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] (13) 0x000c1248 main + 0x404 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] (14) 0xc017d964 _start + 0xb4 [/usr/lib/libc.2] (15) 0x001a7d08 $START$ + 0x178 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] Error (system problem) 689: # Compiler received signal 11 [HP aCC 3.74] -E +Maked ICE on a conditional with new - Key: STDCXX-484 URL: https://issues.apache.org/jira/browse/STDCXX-484 Project: C++ Standard Library Issue Type: Bug Components: External Environment: HP aCC 3.74, 3.73, but not 3.63 Reporter: Martin Sebor aCC 3.73 and 3.74 crashes generating dependencies for the code below: $ cat t.cpp aCC +Maked -E -V t.cpp void foo (int i) { char a [1]; char *p = i sizeof a ? a : new char [i + 1]; } aCC: HP ANSI C++ B3910B A.03.74 Signal 11 ( 0) 0x00298924 sighandler__FiT1 + 0x134 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 1) 0xc022c328 _sigreturn [/usr/lib/libc.2] ( 2) 0x0026b76c synthesize__15LibraryRoutinesF19LibraryRoutinesEnum + 0x7c [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 3) 0x0026f7dc enter__15LibraryRoutinesF19LibraryRoutinesEnum + 0x10 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 4) 0x001ca0d8 lookup__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicListXTP4 + 0x168 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 5) 0x001c9e84 find__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicListXTP4No + 0x9c [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 6) 0x001a1e64 hasPointerToMemberComing__12PreprocessorFQ2_12Preprocessor8PTMStateP11Declaratio + 0x844 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 7) 0x002375f4 isProbablyAnIdentifier__12PreprocessorFb + 0x54 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 8) 0x001c7b7c resolveIdentifier__12PreprocessorFP12ScannerValue11StringToken + 0xbd4 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] ( 9) 0x001c5a30 nextToken__12PreprocessorFP12ScannerValue + 0x210 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] (10) 0x0026adc4 DoCompile__8CompilerFv + 0xd44 [/amd/packages/mdx/hpux/compilers/hp/aCC374_11.31/opt/aCC/lbin/ctcom.pa20] (11) 0x000b347c DoCompile__8CompilerFP6Buffer + 0x34