From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108274 invoked by alias); 21 Feb 2017 16:51:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 108260 invoked by uid 89); 21 Feb 2017 16:51:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=H*i:sk:80e4049, realized, H*f:sk:80e4049 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Feb 2017 16:51:05 +0000 Received: by simark.ca (Postfix, from userid 33) id 0A7EE1E74E; Tue, 21 Feb 2017 11:51:04 -0500 (EST) To: Pedro Alves Subject: Re: [PATCH] Default initialize enum flags to 0 X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 Feb 2017 16:51:00 -0000 From: Simon Marchi Cc: Simon Marchi , gdb-patches@sourceware.org In-Reply-To: <80e4049b-0dc1-c396-e788-36e07015c69c@redhat.com> References: <20170220214548.18024-1-simon.marchi@ericsson.com> <73ee5ceea586400d0ec017304ce3d3f0@polymtl.ca> <80e4049b-0dc1-c396-e788-36e07015c69c@redhat.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.3 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00569.txt.bz2 On 2017-02-21 06:16, Pedro Alves wrote: > On 02/21/2017 03:01 AM, Simon Marchi wrote: > >> >>> #2 - The other reason is that it's nice IMO to leave enums and enum >>> flags >>> easily interchangeable -- i.e., make them behave as close as >>> possible. >>> Having one be default initialized, and the other value initialized >>> means that when changing variables from one type to the other >>> one needs to consider that aspect. >> >> Well, they're not directly interchangeable in C++, which is the whole >> point of having enum flags. > > TBC, by "interchangeable" I meant, when you refactor/redesign code and > decide the flags would be better as normal enums, and vice versa. > > Passing an enum flags to a function expecting a raw enum > (because it was compiled in C) and vice versa would probably > not be interchangeable at run time, depending on ABI. > >>> #3 - Default initializing to zero can hide bugs that would otherwise >>> be caught with -Winitialized. >> >> (-Wuninitialized?) >> >> I don't really understand how this could hide a bug. > > I was thinking of the "this code path should have set flags to > something > non-zero, but the compiler didn't warn because the variable > was initialized" kind of bug. > >> When we don't >> initialize the field in the default constructor, does -Wuninitialized >> issue a warning for this? >> >> my_flags flags; >> flags |= some_flag; >> >> I tried quickly and it doesn't seem so. As stated above, if we have >> the >> default constructor of the enum flag initialize the value to 0, it >> won't >> be a bug in C++, but it will generate a warning in C where plain enums >> are used. > > Bah, I assumed it did! But now that I try, it really doesn't. :-( > > I filed a GCC bug now: > > [-Wuninitialized] referencing uninitialized field of POD struct should > warn > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658 Oh so it's only in some very specific cases that the warning is missing... > This was my strongest argument, and I'm left without it, so... TBH, my original motivation was so we could be lazy and leave out the initializations, I only realized while reading your message that it was actually a problem :). >> So if we don't initialize the value to 0 in the default constructor, >> compiling this code in C++ will be a bug but will not generate any >> warning. This seems very error prone to me. > > Agreed, unfortunately... > > Looking at the patch: > >> @@ -117,6 +117,7 @@ private: >> public: >> /* Allow default construction, just like raw enums. */ >> enum_flags () >> + : m_enum_value ((enum_type) 0) >> {} >> > > The "just like raw enums" comment is no longer true. Please tweak > that. > > OK with that fixed. Thanks, pushed with that fixed.