On Thu, Dec 27, 2012 at 4:22 PM, Joerg Sonnenberger <[email protected] > 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 < > [email protected] > > > 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...
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
