You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@stdcxx.apache.org by vi...@apache.org on 2008/02/26 23:41:53 UTC
svn commit: r631410 - /stdcxx/trunk/include/loc/_money_put.cc
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 <vi...@roguewave.com>
* include/loc/_money_put.cc: Eliminate uninitialized variable
warning.
Modified:
stdcxx/trunk/include/loc/_money_put.cc
Modified: stdcxx/trunk/include/loc/_money_put.cc
URL: http://svn.apache.org/viewvc/stdcxx/trunk/include/loc/_money_put.cc?rev=631410&r1=631409&r2=631410&view=diff
==============================================================================
--- stdcxx/trunk/include/loc/_money_put.cc (original)
+++ stdcxx/trunk/include/loc/_money_put.cc Tue Feb 26 14:41:46 2008
@@ -67,8 +67,8 @@
typedef moneypunct<_CharT, false> _Punct0;
typedef moneypunct<_CharT, true> _Punct1;
- const _Punct0* __pun0;
- const _Punct1* __pun1;
+ const _Punct0* __pun0 = 0;
+ const _Punct1* __pun1 = 0;
if (__intl) {
__pun1 = &_RWSTD_USE_FACET (_Punct1, __flags.getloc ());
RE: svn commit: r631410 - /stdcxx/trunk/include/loc/_money_put.cc
Posted by Martin Sebor <se...@roguewave.com>.
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 <vi...@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
RE: svn commit: r631410 - /stdcxx/trunk/include/loc/_money_put.cc
Posted by Travis Vitek <Tr...@roguewave.com>.
>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 <vi...@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