Re: svn commit: r555970 - /incubator/stdcxx/trunk/tests/src/fmt_bits.cpp

2007-07-13 Thread Martin Sebor

[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

2007-07-13 Thread Martin Sebor

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

2007-07-13 Thread Martin Sebor

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

2007-07-13 Thread Martin Sebor

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?

2007-07-13 Thread Martin Sebor

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

2007-07-13 Thread Eric Lemings (JIRA)

[ 
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

2007-07-13 Thread Eric Lemings (JIRA)

 [ 
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

2007-07-13 Thread Martin Sebor (JIRA)

[ 
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