stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor" <se...@roguewave.com>
Subject RE: svn commit: r631410 - /stdcxx/trunk/include/loc/_money_put.cc
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...

Martin

-----Original Message-----
From: Travis Vitek [mailto:Travis.Vitek@roguewave.com]
Sent: Tue 2/26/2008 3:59 PM
To: dev@stdcxx.apache.org
Subject: RE: svn commit: r631410 - /stdcxx/trunk/include/loc/_money_put.cc
 
 

>From: vitek@apache.org [mailto:vitek@apache.org] 
>
>Author: vitek
>Date: Tue Feb 26 14:41:46 2008
>New Revision: 631410
>
>URL: http://svn.apache.org/viewvc?rev=631410&view=rev
>Log:
>
>2008-02-26  Travis Vitek  <vitek@roguewave.com>
>
>	* include/loc/_money_put.cc: Eliminate uninitialized variable
>	warning.
>
>
>Modified:
>    stdcxx/trunk/include/loc/_money_put.cc
>

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.

  http://svn.apache.org/viewvc?view=rev&revision=330842

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

  http://svn.apache.org/viewvc?view=rev&revision=627612

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?

Travis


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