From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id B25DC3857C49 for ; Sat, 24 Oct 2020 08:49:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B25DC3857C49 Received: by mail-ot1-x331.google.com with SMTP id n11so3753797ota.2 for ; Sat, 24 Oct 2020 01:49:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IXFxuRLLdyE4BA06yR80zmvNmOOjZQ+y7QPCKw6h0+4=; b=SyIN6H4TsWd1e+xSXOBvR9+7pe/n6RwU7cilEsiTDCH4AMSRePNkjnKujHu5t3dBoq 1IJC97HFr1oPxneoVtP31sfauCmtGVQ8UMWrVFM8ykU9MScwTM+qxWSNiWqNtN5XYDaZ vUU6C7JPpm+odoonGtuFu7EExE/m98wEHhbrxTHANUZLGT3g0+8PKsmU6E8nK5sbr4JJ dP0ucuwHyXBJfBXbfWVvUyGJKCljO39QZrLAnlmD1uhD19aY6OChS9EQrBW05Xo8CG3P yZSJ/68OCd+movbueBXwCoVF/3RhX4Vm9ktgg6fXW9/IFZ+XOZb8LytVfTb2K493rYMo P6hQ== X-Gm-Message-State: AOAM533vq+JXZIonScLtgtifygQ0Xif+E5cmI14HwRxvxyKDjEW4cEL3 Hh8ISGqb3HlhFZ4ZMWUDWEt0iaq7cQchIJQ6hKYEw4agSuGCEA== X-Google-Smtp-Source: ABdhPJzMcAG6tjLnw6CQu2TTAZsO4rBgxmkN3cfIPBbI1mHIBHLhNcs2N6S/njP1w+JqEBP/bmxNhpphptyRSkOalwk= X-Received: by 2002:a9d:6c1a:: with SMTP id f26mr4420839otq.1.1603529389747; Sat, 24 Oct 2020 01:49:49 -0700 (PDT) MIME-Version: 1.0 References: <20201023203832.GH2672@gate.crashing.org> <41334120-9251-abaa-c6a2-a647fb34f123@yahoo.com> In-Reply-To: <41334120-9251-abaa-c6a2-a647fb34f123@yahoo.com> From: J Decker Date: Sat, 24 Oct 2020 01:49:40 -0700 Message-ID: Subject: Re: __attribute__ to selectively disable -Wmaybe-uninitialized To: gcc-help X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, FREEMAIL_REPLY, HTML_MESSAGE, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Sat, 24 Oct 2020 08:49:52 -0000 --- Test.c ----- #include #include void a( void ) { int buf[2]; buf[0] = 0x12345678; buf[1] = 0x12345678; } void f( void ) { int n; int m; for( m = 0; m < 2; m++ ) { switch( m & 4 ) { case 1: n = 3; break; } } printf( "%d\n", n ); } int main( void ) { a(); f(); } ---- n is definitely never set, and I can't get a warning generated... was more looking for a false-negative example (where N is definitely always set by the usage... it prints whatever buf[0] was set to in a()... (added A so it didn't print 0, and I could demonstrate some control; tried just doing a printf or something before hand but ended up with '0' anyway, which looks sort of like it might have been initialized to '0' (it wouldn't have been, but one might feel that it did). This is the sort of thing that happens... a series of events happen which MUST happen before a thing is used, otherwise a return or other condition which is not a direct test against that variables would trigger a bypass of usage or early return... I have several places where that warning has shown up, and I've considered adding a fake initialization to a value that I know would never be used and would always be replace by a real value (yes it's only a couple ticks to set a variable, it's still a write to memory that's not necessarily required; and who cares about generating heat?) On Fri, Oct 23, 2020 at 2:51 PM mark_at_yahoo via Gcc-help < gcc-help@gcc.gnu.org> wrote: > On 10/23/20 1:38 PM, Segher Boessenkool wrote: > > Yes. And you usually should make trivial changes to your program if the > > compiler warns, even if you consider that unnecessary -- just so that > > you will not miss other warnings! > > > No, but you can write your code so that it more obviously does not use > > unitialised variables. This is an Even Better Thing(tm). The compiler > > will understand it, but much more importantly, human readers will > > understand it as well! > > It's often (maybe always) possible to reorder/refactor the code as you > suggest. Sometimes (maybe often) that results in convoluted logic and > control flow, needlessly repeated code sections, gratuitous (possibly > inline) functions, and the like. The cure being worse than the #pragma > disease. > > > > -Wmaybe-uninitialized has a LOT of false positives if you use anything > > but the strictest, simplest control flow. It's the nature of the beast. > > That's the point. There will always be false positives. Sometimes the > programmer *does* know more than the compiler. IMO GCC could benefit > from a better way to selectively turn them off. > > > >> 5. I now see something similar was requested in 2012 in > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288 but seems to have > >> been dismissed with a variation of #4. > > > > It wasn't dismissed, that PR is still open. > > Sorry, I was using "dismissed" colloquially. The response was > dismissive, and from what I've been able to find nothing has been done > in the succeeding 8 years. > > But, yes, that's the nature of the open source (in general) and GCC (in > particular) beast. > > -- > MARK > markrubn@yahoo.com > > >