Message ID | 20170220214548.18024-1-simon.marchi@ericsson.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 89912 invoked by alias); 20 Feb 2017 21:46:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 89902 invoked by uid 89); 20 Feb 2017 21:46:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.2 spammy=enum_flags X-HELO: sessmg22.ericsson.net Received: from sessmg22.ericsson.net (HELO sessmg22.ericsson.net) (193.180.251.58) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Feb 2017 21:46:14 +0000 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 31.04.08672.4A36BA85; Mon, 20 Feb 2017 22:46:12 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 20 Feb 2017 22:46:10 +0100 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from elxcz23q12-y4.ca.am.ericsson.se (192.75.88.130) by DB4PR07MB396.eurprd07.prod.outlook.com (10.141.236.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Mon, 20 Feb 2017 21:46:08 +0000 From: Simon Marchi <simon.marchi@ericsson.com> To: <gdb-patches@sourceware.org> CC: Simon Marchi <simon.marchi@ericsson.com> Subject: [PATCH] Default initialize enum flags to 0 Date: Mon, 20 Feb 2017 16:45:48 -0500 Message-ID: <20170220214548.18024-1-simon.marchi@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: DM5PR15CA0017.namprd15.prod.outlook.com (10.173.207.155) To DB4PR07MB396.eurprd07.prod.outlook.com (10.141.236.19) X-MS-Office365-Filtering-Correlation-Id: 2a0dd420-f828-46f3-7329-08d459d9e18d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DB4PR07MB396; X-Microsoft-Exchange-Diagnostics: 1; DB4PR07MB396; 3:ZPgxa7r80B7/TqYcojIUeg6p+Vf9n15HvZQRjVKE/02bwWM6Ef1GvEtRupepNiZpgX23wx8A4Tzpo3EEA0LmbDAKJ/JlVsDc6v0F+ADGElUCvMF4vN8hT7TegiE8L3t4dPnpCxOJU8ola8Ou/t5U/M220CKb/I0Lw+TjNNgg9QAfBdVnAbby0I2tAOEEgGqomX5xzrCYKVe1Ie1vYj/z0FdzZ0FURFM+6L8zlp88cIoCwqu+T1Hpmpn26dhhLkYw2iPauI1m+1fz1pDtFtElyA==; 25:iV3QBiF8dWHm6zdic3vpBvsZSOtNJUtTehvZnRNu0S81vGkZyy4HnQLqcMw7tqcF4WtulcVFiBDyvIqvwBE1bq3NXzQsGJuy0xgU+Tgx9DxKFw+aWchBKbxkhiVsTjbgBS7KdHAWngsOaiKBqR4csAsCYyRJyAGUCJ7/AvJjDd/OSJmdpP+EqNSt+xKalta+VoJkd0j5F0E7pSpnfzVSJ9C7zy94rQhFS8N9Wz4IQPU+ejdGcZKRJWgeKiYKNVlvQoGer9PPcmmlPea5o25h+Uhn8io73bSpLzgLiqBS72Zxp3C6tO9oxd6+/vn4ovIzlKm3zUo1JAcywUrY3KK5JgmW6NQJ4QCYQjvE/gQiLSz2dZKke3kQfFsPLWcP3TNPJTuaU4+ZPYMOfqnVFsXb3falhPyFVrcr/1K+dP8Eo60zVITupmCTXMg2VVcBhxw+cL0HNV5c2sP9qq8KJod6cg== X-Microsoft-Exchange-Diagnostics: 1; DB4PR07MB396; 31:0N7Gca1fzVZWBh3MxMjEPEjMVx2uorrY/+w33GRxHU7w9PeHxV0P/fa6MJtHxdHISzg49QUUDrcwRobv7+iUCjsfeEZXmnHUekprcHKskXU3XPSmjljuwKudk2uMvgAa9L0vEHtw3vGbg6iS5u4lWKFM+K7VzCZMPe4RO4W8TaS4tir9HcxTIvXJIPS0QjY1nTbjdy5+Bl7Wy7wMrO9A9q8dj/S6W1gcoJAp+k8BZBQ=; 20:QwxTcGupqRp670o0OWH1as7wa4IzxQUYG/ty6TY4kqrIOpyMwPA6MLPLa/jUfkoPjlrXH6i/0XZ36fcKksnM/ixZEd27i9dPDOMw/WrgYgpbTjBe7B7eb8B6QrPmXJc1tiNc6jsMwxpls9SyAVtvTdnUy0bwNBCVJkhQONQQOZ8ZnvIFBDp8dyEBBrz7EFaXbdkYExig4v/FZHt60y7XgVlr1OwNvl296VFE6HzIyXpZ995YLTviqKsVfp2a4JujJ4qzrdq2E7DuvLtpIp/GT+mzVi/pRbmyz1x0H6y4L4Sc/sVYVzGPRMgJg+wjOle9mTiRYS9HzMvkbjnvWyqvDT+zrKDzd3PqWHJ5hKN2HAYyrQm7tQHplAn0YUdjvaBu+3G4E1yqQeTH96Ls6TjnfgbfJ3NVh/pXwXaQXTSs1+wIT/Pvr6ZNfwfr4J8JdWLs4G/S6tLMjwOFxFdf8YMYOJzGLQEHYrbpT+ePiAPjocc7+8KFRZmtaFcJQSn86ciO X-Microsoft-Antispam-PRVS: <DB4PR07MB3965539417FE5E74ED4206AED5E0@DB4PR07MB396.eurprd07.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:DB4PR07MB396; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB396; X-Microsoft-Exchange-Diagnostics: 1; DB4PR07MB396; 4:gU5Qubwd2COIOyyt+/0G6d3fnhzfPAkhrkO9sXE6cTUZyg933fv723anr0811ThR6V5IPLfoy76B5BGbsNF2SGf7vJZEJDJvkow+KNQX8bHmFhkTP66XXVaa2k5C/3MFWLqVALnyC0ZilV8JHdZTu+rSo8UKgtJ2WJA5PTOZx51hluEk48RLDGHoVK1LjaHUiTRQXJQI+uDhaeFTg5afXNja89j6Hf+J/pW4MRWq0ZTNHswfeBypTnhCXljGekwJXo8JvymJ0F0SA9E1qDKV3pf2VxYKGyNOlejqHahy7zFTwvkMGKDN3GYo5U+8MdTyx5gm4+aBHLytrU+OzX82kiW++gm9Yg9pR1yGoMS+dMmgDDkZvHeHqERiMKzbOrGoRs8lhbtqywTOPN9GPKCYyWFR/zoXO1iQzqfs4nvtScyzfOKZDKPeYtYO6QRRWr8fVfeZPF/PY8A8go5gofeBbXMILezM9uD/+nKIqk0Z6xbmvfZJTONB11X/I3U70i3iTu3byraSw3p4ZeM2xQHR1PvhpFZJQcw0a8epNCMpXHnIlTV7608nQwydeFoyU0tfWULmNTA83MMUGW2rW4aoJOkaFqoFShH7pjAyJcV1S4E= X-Forefront-PRVS: 02243C58C6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(39450400003)(189002)(199003)(54534003)(3846002)(2906002)(189998001)(6116002)(86362001)(25786008)(6512007)(50226002)(5660300001)(8676002)(81156014)(81166006)(68736007)(66066001)(6506006)(1076002)(6486002)(92566002)(97736004)(4326007)(450100001)(6666003)(6916009)(36756003)(101416001)(38730400002)(107886003)(110136004)(33646002)(53936002)(106356001)(105586002)(48376002)(50466002)(47776003)(50986999)(5003940100001)(2351001)(42186005)(7736002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB396; H:elxcz23q12-y4.ca.am.ericsson.se; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB4PR07MB396; 23:yR5Un8/q8eGJcSejCKKIg9JUjoRn0sMf2kd2aXLMbz?= =?us-ascii?Q?yguqi48JPGpf3+YUcYFZZ+A3ePL38fbb30haOe2gPkxVlZI4oetoHIYzo2NW?= =?us-ascii?Q?gHjeTDNAthggkwYx3mfb5+rPOiekDRdp44qY9Vbv5F65jf5So1JPiTR55UUq?= =?us-ascii?Q?ktMoHCI6kGoJgqkrJrl4VxZR0eJgq5lSjTbNtNSx7J/Qhk8TjfPG/ykZwbw/?= =?us-ascii?Q?TxUUk+1yotHtelNOcNkvcHD6RL0PEkFnZXQlNwdFvtCVG7EtN8S16d5ioWpg?= =?us-ascii?Q?IvjSD5+8ZrXFc0Wrr/ow+iTMXYV6UvBJ+uxR8hjVjIzNVXHg9qOKIp9hPNkv?= =?us-ascii?Q?qdUj9sroSIIqD1dC6+s5jjhvY8lgY9sICjMG5xtvUdoeSVbtMOyIRRjV6Jvm?= =?us-ascii?Q?SneCDedg2kYkMF3o0zv1qyYP+gjQGaqpKqmN37xw2qzCApb93MQIFWTxvHYP?= =?us-ascii?Q?DVo7NsPPjOqXtzeg70JBHN33601G6RDB713p9suSMUQ4PYEbizabRXSWDmdY?= =?us-ascii?Q?mjaXVUNp+IJqOPUqIg/jN26r57wsBwQSvc9j9Tj/9vQlFIwIuGznelmXglhj?= =?us-ascii?Q?0dQPuET2LOlgxqM2QjzwdPRFZj+IkFM3WTz2MUFYY4qHbk08OB2TsTRI3cSO?= =?us-ascii?Q?Ji+9aFdaHq/Ygu+9pqcVMXspNHdcTEfWkIuS/cuttkcP7/apzFsm5FxyhEzM?= =?us-ascii?Q?cSsRxMeyTQIK1i4ucS++s6VSB+JRW3nugXXTfR2kf2eum+w+xN+PjSB/iLL6?= =?us-ascii?Q?fDnN+uDQ6hfD8BxZ9Q0/O+oKimWdOYtDCUrNDEMoNGR221kuyaOeoFd06wOH?= =?us-ascii?Q?+GE31YWJXWsjp+mbiUEPpx2r9IutRghVVoEQYQxXt1bYOhGMm+/5H9Js+cCr?= =?us-ascii?Q?adjhmK3K7TTwNc1npapPjAijD/dcpFoQWOgdHT+D7ZebUfVt/0DHuCZnJDeT?= =?us-ascii?Q?3wJXXS8gZc4hNhCLmEYua7j9iWvT+cFRRKexpFiar0qaptPrkyXpDWoMHaTt?= =?us-ascii?Q?A5Wma92KosHnZrcpMmURAT3Buwrg2e6xVNWd6NN83Yh+yLpTkHeBEx1TKPo7?= =?us-ascii?Q?tbP8DIkUoqif0jzUMKx4Vk382EcHIxgcTXBdg0VQqsKnNXFSGe5Mza29cs8N?= =?us-ascii?Q?52OE/4XCuyY2YxIN+S4qDo9S3+1G+kdRzx94PntSbfJRBaBSzS8w=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB4PR07MB396; 6:d0+TOX8/n0u/yllikFxDgxJqSWtEbuB50P0P6UaZPY1k1gUKEbU5rBfeF1Gx1mzYCINDRDqMSGSLNryx8oY3DX4SPweC/eqFSM6qehcHRteKb6lFKtLFrlo3AkUMXVMHtXpa/X9MtUoQI5HuwDJlmPRBXYoVcF3pxUG1LJECy33BaNvZrexxXCyXfYouPKb0X6leeVWpikKtkcOzQSzLX1V9HeYDyJ1lOfU21Z12xpyoJ2E9Fr1Clh4recmGMGKsDACNYqX7YIUrgU76cN2yP2UIMVv4y+f86gQX8FjVN/jAAmESaIjJRBi4Q3vsGJyTzcgR3/WcNgged61WETo6trXRWqq0nk3SRT/eSzJ4f75E8NTl5G8RXzLStGS2mfv71YmCs3qBZL9xVE8woaY4ow==; 5:+j75ugqY0tTmDHBgYSG4+Fs+LVjfdgdmZBttD0xOGAzTpA8qosHQxAaB9acQ2WnNvjdBSTXcRf/kPPOEyGGwRSrv23yWEpv9hZMv2/oULvLAw6u2aUqbw9PNwT0cy6aFw7KDn00jIuGsHdDG0GXK4iow3Sv2f+ovP2yDuwSe/F8=; 24:DUg1NJBZXF1cx27n3PyNVtNSk+ivo4yyev90JldJbLPmdTwMNPDeEl7F/42BHqxZYFqi9gltHo0RtBLIf5IHtssiwJeQHHA6iNG5RHEht5o= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB4PR07MB396; 7:Aqf2tworObG5A3GctF2hCEu0rDWkIddCm8vPpZre2lrrvdfIo09atPFQdf7gbD19+M6RPvJLib5oQLOlAMfQIf2rZU79QDJES8DDKmiFmWD2pKVgjpH96e4dcJbwm9ElWOCW+w/Qul7/L5N0qIiJzeI8x3OUNj20zSc/YxnBLxrUeyou0RSifElG7/zQiZDGK/kr6sM6b/cuBTBEtPFjdecOaRHVWMBXIwvRHc+qjKg8wY4McYfjTSu+niEk2Zk+iuV4W9s0lR+e/NLtIKFTN2kZguh2aNWu8q+baGr5cWUNOp0GNUdYcofNF5yQeIpxAu+yDWh9csVJHrMAOMUP4g== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2017 21:46:08.7220 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB396 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes |
Commit Message
Simon Marchi
Feb. 20, 2017, 9:45 p.m. UTC
... 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. --- gdb/common/enum-flags.h | 1 + 1 file changed, 1 insertion(+)
Comments
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]. #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. #3 - Default initializing to zero can hide bugs that would otherwise be caught with -Winitialized. [1] - Trevor expressed something similar before too [2]: https://sourceware.org/ml/gdb-patches/2016-11/msg00114.html [2] - Yes, I need to find some time to post a v2 of that series. :-P (It's baking slowing on my github.) Thanks, Pedro Alves
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
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 This was my strongest argument, and I'm left without it, so... > 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, Pedro Alves
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.
diff --git a/gdb/common/enum-flags.h b/gdb/common/enum-flags.h index 5b8c3ebc32..b1cf9a4644 100644 --- a/gdb/common/enum-flags.h +++ b/gdb/common/enum-flags.h @@ -117,6 +117,7 @@ private: public: /* Allow default construction, just like raw enums. */ enum_flags () + : m_enum_value ((enum_type) 0) {} enum_flags (const enum_flags &other)