[cfe-commits] [PATCH] [libcxx] cleanup a few compile warnings emitted by GCC

[Chandler Carruth]

On Thu, Dec 27, 2012 at 4:22 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:

> On Thu, Dec 27, 2012 at 04:05:37PM -0800, Chandler Carruth wrote:
> > On Thu, Dec 27, 2012 at 4:01 PM, Joerg Sonnenberger <
> joerg at britannica.bec.de
> > > wrote:
> >
> > > On Thu, Dec 27, 2012 at 01:49:06PM -0500, Howard Hinnant wrote:
> > > > > @@ -4583,7 +4584,7 @@
> > > > >  string
> > > > >  __time_get_storage<char>::__analyze(char fmt, const ctype<char>&
> ct)
> > > > >  {
> > > > > -    tm t = {0};
> > > > > +    tm t = {0,0,0,0,0,0,0,0,0,0,0};
> > > > >      t.tm_sec = 59;
> > > > >      t.tm_min = 55;
> > > > >      t.tm_hour = 23;
> > > > > @@ -4729,7 +4730,7 @@
> > > > >  wstring
> > > > >  __time_get_storage<wchar_t>::__analyze(char fmt, const
> > > ctype<wchar_t>& ct)
> > > > >  {
> > > > > -    tm t = {0};
> > > > > +    tm t = {0,0,0,0,0,0,0,0,0,0,0};
> > > > >      t.tm_sec = 59;
> > > > >      t.tm_min = 55;
> > > > >      t.tm_hour = 23;
> > > >
> > > > Rejected.  tm contains *at least* 9 int data members.  The portable
> and
> > > > concise way to zero initialize this struct is with the single {0}.
> > >
> > > What about using memset as alternative?
> >
> >
> > Why? The compiler warning from GCC is simply wrong. The other members are
> > in fact initialized. I see no reason to use a more verbose construct
> which
> > requires a declaration of an external function merely to avoid a patently
> > incorrect warning.
>
> The compiler warning from GCC is for the (common) case that a field is
> added later and so the initializer depends only on the default value of
> the field. That warning is helpful for plain C, but not so much for C++
> data structures, where constructures serve the purpose of preserving API
> compatibility.


There are common patterns that are pretty well established in both C and
C++, that should not trigger such a warning. I think '= {0}' is one such
pattern...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121227/5d0813d9/attachment.html>