stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor" <>
Subject RE: svn commit: r631410 - /stdcxx/trunk/include/loc/
Date Tue, 26 Feb 2008 23:22:38 GMT
FWIW, I confirmed with HP that the aCC warning is bogus (i.e., it's
a compiler bug). The gcc warning looks suspicious too but I'm not 100%
sure it's a bug. Since the warning comes out of a library header (and
will pop up in pretty much every translation unit that #includes the
header) IMO it's important to silence it. IIRC, there might even be
something about it in our release policy -- which, incidentally, we
still need to bring up for a vote...


-----Original Message-----
From: Travis Vitek []
Sent: Tue 2/26/2008 3:59 PM
Subject: RE: svn commit: r631410 - /stdcxx/trunk/include/loc/

>From: [] 
>Author: vitek
>Date: Tue Feb 26 14:41:46 2008
>New Revision: 631410
>2008-02-26  Travis Vitek  <>
>	* include/loc/ Eliminate uninitialized variable
>	warning.
>    stdcxx/trunk/include/loc/

I just looked at this, and I've apparently made a small boo-boo. Martin,
you originally made a similar change on trunk some time ago.

Just recently, you undid that change to resolve a warning on HP.

So I've just undone your fix for HP in a way that isn't consistent with
what is on the branches/4.2.x. Ugh.

So now the question is, what should we be doing here. We have
conflicting warnings. I'm actually a little surprised that the HP
compiler doesn't warn if the values are left uninitialized. Instead of a
potential null pointer dereference, you would have a potential garbage
pointer dereference, which in some cases may be worse.

Should I just undo my 'fix' on trunk, or should I take a half hour to
try and find a way to placate both compilers?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message