From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54183 invoked by alias); 21 Feb 2017 03:01:24 -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 53935 invoked by uid 89); 21 Feb 2017 03:01: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*f:sk:d8c3b97, H*i:sk:d8c3b97 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 03:01:05 +0000 Received: by simark.ca (Postfix, from userid 33) id 0EEC61E18F; Mon, 20 Feb 2017 22:01: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 03:01:00 -0000 From: Simon Marchi Cc: Simon Marchi , gdb-patches@sourceware.org In-Reply-To: References: <20170220214548.18024-1-simon.marchi@ericsson.com> Message-ID: <73ee5ceea586400d0ec017304ce3d3f0@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.3 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00562.txt.bz2 On 2017-02-20 18:18, Pedro Alves wrote: > On 02/20/2017 09:45 PM, Simon Marchi wrote: >> ... so that we don't need to do it manually, and potentially forget. >> For example, this allows to do: >> >> my_flags flags; >> >> ... >> >> flags |= some_flag; >> >> gdb/ChangeLog: >> >> * common/enum-flags.h (enum_flags::enum_flags): Initialize >> m_enum_value to 0 in default constructor. > > Not sure I really like this. 3 reasons off hand. None are > very strong, but let me put them out nonetheless: > > #1 - I have some desire of creating a "gdb/gnu template library" dir > and moving these utilities there, in order to share them with more > projects (e.g., gcc, and who knows, gold and who knows other parts > of binutils that might want to convert to C++ in the future), and > it'd be nice to keep the type behaving the same in C and C++ > modes (that's why I had left the !__cplusplus branch in > the file). [1]. I had the intuition that trying to keep the same behavior as plain C enums was a reason the field is currently left uninitialized. > #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. But let's assume that they are for the sake of argument, and that we are initializing the value to 0 in the default constructor. If you want to switch from enums to enum flags, the explicit zero-initializations you have in your code will now be extraneous but harmless. If you are going from enum flags to enums you might be missing some initializations, but -Wuninitialized will tell you. If you decide to use ints with #defines instead, then -Wuninitialized will tell you as well. If you are switching back and forth between enums and enum flags in a C program, -Wuninitialized should warn you either way, and you'll have the same bug in both versions (since the enum flags type is a direct typedef to the enum type). If the context is a program that is both C and C++, like GDB was not so long ago, then omitting an initialization will not be a bug in C++. It will be a bug in C, but then again -Wuninitialized will warn you. > #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. 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. 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. Simon