From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic308-29.consmr.mail.bf2.yahoo.com (sonic308-29.consmr.mail.bf2.yahoo.com [74.6.130.228]) by sourceware.org (Postfix) with ESMTPS id 0DA2B3858D37 for ; Tue, 27 Oct 2020 08:03:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0DA2B3858D37 X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1603785800; bh=RotIkhV+9cNgoTatnn0QpnvYP00KvdRMpJMOAtFnhCF=; h=Subject:To:From:Date; b=PDJASffy+o3TDHFEztLYUvNTXH7QD/0SGzUm+BG4LOyCtdA35JP6DsNfeJCRTeHG54GVCbjz9/8O/in1rsQKlXQ1KkxGioHIu2Np7NmKy2ypwo5L1YoNESZIHJmCNUhgN6PwnkPAh5Pk+kB8Q5KKr+Voo51bdWMlVWI7vceXXtykiyA3v4rGVErxQTDLDP+6Y9ihoVS7h3wD6Ung6ue6haSzy4t6RY7fXUhTe59KsztOUoRNFg7Yht+IzEvoJqtnNEfRZvkzmIIKSeP7dg4hwVzln7BE9gYkeIeXZm9vRI0sHMwzDj07bQ4lBokPIHuHKM/3dZVZRtA92cx4NwBMsg== X-YMail-OSG: N_6BpMEVRDvd.miR6A7lED5GPdAEx7ojsA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Tue, 27 Oct 2020 08:03:20 +0000 Received: by smtp425.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2cacc070862ccb2bf79eb9b490597675; Tue, 27 Oct 2020 08:01:19 +0000 (UTC) Subject: Re: __attribute__ to selectively disable -Wmaybe-uninitialized To: Segher Boessenkool Cc: gcc-help@gcc.gnu.org References: <20201023203832.GH2672@gate.crashing.org> <41334120-9251-abaa-c6a2-a647fb34f123@yahoo.com> <20201024183217.GN2672@gate.crashing.org> From: mark_at_yahoo Message-ID: <316cf378-9eca-2fe6-7ba7-e3525abd2d30@yahoo.com> Date: Tue, 27 Oct 2020 01:01:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20201024183217.GN2672@gate.crashing.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.16868 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 08:03:23 -0000 (Apologies for the delayed response. I receive gcc-help posts, including others from you, without problem, but this one which I'm particularly interested got caught in my spam filters.) On 10/24/20 11:32 AM, Segher Boessenkool wrote: > I have to disagree with you there. Well-factored code is *good*. The > compiler can (and will) do all the obvious optimisations; you should not > obfuscate your program by doing them manually (and hinder the compiler's > optimisers, and introduce bugs at the same time). FWIW, I agree. > "Gratuitous functions" is only a problem if you have trouble naming > them. Which sometimes is a problem, sure, but most of the time that > simply shows that your factoring isn't so good. I always factor out common code, and attempt to give it informative function/class/method/namespace/etc names. I tend *not* to factor out code that is only used in one place merely to follow coding standards that forbid lengthy functions. No spaghetti code, but I have no problem with: void func() { // part1 // ... // part2 // ... // part3 // ... } compared to: void func() { part1(); part2(); part3(); } regardless how long the "parts" are (assuming they aren't reused elsewhere). And, yes, I understand inline functions. > -Wmaybe-uninitialized only has false positives for non-trivial control > flow. Which you probably shouldn't have in your source code anyway. Whether or not it gives false positives seems unpredictable. My code's control flow is: void func( bool with_buffer) { char *buffer; if (with_buffer) buffer = allocate(); while (still_working()) { other_processing(); if (with_buffer) process_buffer(buffer); yet_more_processing(); } } This test demo does not give the warning. The real program, with identical control flow but much more intermediate code, does. Yes, there are many ways to refactor this code (separate "with" and "without" functions, two different loops inside "if" and "else" branches of "if (with_buffer)", etc). IMO all of them obfuscate the above simple control flow, not the opposite. > If you insist on using constructs that -Wmaybe-uninitialized cannot > handle, then do not use -Wmaybe-uninitialized? I thought we agreed that warnings are A Good Thing. > It should arguably not be enabled by -Wall, just by -Wextra. FWIW, I'm using -Wextra. As per above, I like warnings. > The only comment was a helpful suggestion. If that is not what you are > looking for, just ignore it, or make a comment yourself? Complaining > that people are "dismissive" because they have a different opinion is > not helpful. The comment was "Why don't just initialize the variable?". In addition to the unnecessary compiled instructions that produces (unless the optimizer is smarter than the warning generator and removes them), it hides the issue in a non-obvious way compared to the explicit pragmas or a theoretical attribute. As you point out, that's been the only comment in 8 years until this discussion -- and I do consider it a discussion, not a "complaint". As you said before, the issue is still open. I considered the comment a "last word", which along with lack of further response to the original issue filer's further points to mean, "we feel this is not needed/important". Whether that's "dismissive" or not is open to interpretation. > If you insist on having an attribute to disable just this warning, you > can implement it yourself (or get someone else to do it for you). Of course. > It > does not have to become part of GCC mainline. *That* is the nature of > Free Software. I'm suggesting the attribute because I want to use it in some open-source software I'm distributing. I also think it would be a good GCC extension in general. Even assuming I had the ability to implement it myself or contract the same, I will not be distributing a custom compiler for my project, so if it wouldn't make it into the mainline (which these emails strongly suggest), that's not an option. > If you cannot convince people to spend their time on > implementing your ideas, then maybe they do not think those are good > ideas? Obviously they/you don't. Pending any further comments regarding my control flow example above, I'll take it that I wasn't convincing and the matter is closed. I do take heart that others (like the 2012 issue filer and some in this short thread) seem to agree with me, or at least that this has been worth discussing.