* __attribute__ to selectively disable -Wmaybe-uninitialized [not found] <caf2f32f-3caf-fc89-0ca6-4c885a7b8ff1.ref@yahoo.com> @ 2020-10-23 20:01 ` mark_at_yahoo 2020-10-23 20:38 ` Segher Boessenkool 2020-10-24 17:06 ` Florian Weimer 0 siblings, 2 replies; 8+ messages in thread From: mark_at_yahoo @ 2020-10-23 20:01 UTC (permalink / raw) To: gcc-help To disable warnings of the form: file.cxx:307:23: warning: 'buffer' may be used uninitialized in this function [-Wmaybe-uninitialized] I have to bracket the variable's declaration, its use later in the function, and sometimes both, with: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wmaybe-uninitialized" // code here #pragma GCC diagnostic pop The necessity to add many of these pragmas makes the code difficult to read. Is there a variable attribute that could be used instead, something like: char *buffer __attribute__((uninitialized)); I can't find anything similar in the "Common Variable Attributes" section of the docs. If there isn't, could one be added? If local variables have attributes that are maintained throughout the compiler phases it seems it would be simple to check for one immediately before printing the warning, no matter how deep in the compilation process. Notes: 1. I understand that -Wmaybe-uninitialized produces both false positives and false negatives. 2. Due to #1 it's difficult to produce a simple test demonstration. 3. I don't want to disable -Wmaybe-uninitialized globally, or for an entire function. Warnings are "A Good Thing"(tm). 4. Please, no lectures on why local variables should always be initialized at declaration. 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. Thanks for any info. -- MARK markrubn@yahoo.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __attribute__ to selectively disable -Wmaybe-uninitialized 2020-10-23 20:01 ` __attribute__ to selectively disable -Wmaybe-uninitialized mark_at_yahoo @ 2020-10-23 20:38 ` Segher Boessenkool 2020-10-23 21:51 ` mark_at_yahoo 2020-10-24 17:06 ` Florian Weimer 1 sibling, 1 reply; 8+ messages in thread From: Segher Boessenkool @ 2020-10-23 20:38 UTC (permalink / raw) To: mark_at_yahoo via Gcc-help On Fri, Oct 23, 2020 at 01:01:13PM -0700, mark_at_yahoo via Gcc-help wrote: > 3. I don't want to disable -Wmaybe-uninitialized globally, or for an > entire function. Warnings are "A Good Thing"(tm). 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! > 4. Please, no lectures on why local variables should always be > initialized at declaration. 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! -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. > 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. Segher ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __attribute__ to selectively disable -Wmaybe-uninitialized 2020-10-23 20:38 ` Segher Boessenkool @ 2020-10-23 21:51 ` mark_at_yahoo 2020-10-24 8:49 ` J Decker 2020-10-24 18:32 ` Segher Boessenkool 0 siblings, 2 replies; 8+ messages in thread From: mark_at_yahoo @ 2020-10-23 21:51 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __attribute__ to selectively disable -Wmaybe-uninitialized 2020-10-23 21:51 ` mark_at_yahoo @ 2020-10-24 8:49 ` J Decker 2020-10-24 18:32 ` Segher Boessenkool 1 sibling, 0 replies; 8+ messages in thread From: J Decker @ 2020-10-24 8:49 UTC (permalink / raw) To: gcc-help --- Test.c ----- #include <stdio.h> #include <stdlib.h> 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 > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __attribute__ to selectively disable -Wmaybe-uninitialized 2020-10-23 21:51 ` mark_at_yahoo 2020-10-24 8:49 ` J Decker @ 2020-10-24 18:32 ` Segher Boessenkool 2020-10-27 8:01 ` mark_at_yahoo 1 sibling, 1 reply; 8+ messages in thread From: Segher Boessenkool @ 2020-10-24 18:32 UTC (permalink / raw) To: mark_at_yahoo; +Cc: gcc-help On Fri, Oct 23, 2020 at 02:51:31PM -0700, mark_at_yahoo via Gcc-help 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. 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). "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. -Wmaybe-uninitialized only has false positives for non-trivial control flow. Which you probably shouldn't have in your source code anyway. If you insist on using constructs that -Wmaybe-uninitialized cannot handle, then do not use -Wmaybe-uninitialized? > >-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. It should arguably not be enabled by -Wall, just by -Wextra. > >>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. 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. > But, yes, that's the nature of the open source (in general) and GCC (in > particular) beast. Uh-huh. 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). It does not have to become part of GCC mainline. *That* is the nature of Free Software. If you cannot convince people to spend their time on implementing your ideas, then maybe they do not think those are good ideas? Segher ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __attribute__ to selectively disable -Wmaybe-uninitialized 2020-10-24 18:32 ` Segher Boessenkool @ 2020-10-27 8:01 ` mark_at_yahoo 0 siblings, 0 replies; 8+ messages in thread From: mark_at_yahoo @ 2020-10-27 8:01 UTC (permalink / raw) To: Segher Boessenkool; +Cc: gcc-help (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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __attribute__ to selectively disable -Wmaybe-uninitialized 2020-10-23 20:01 ` __attribute__ to selectively disable -Wmaybe-uninitialized mark_at_yahoo 2020-10-23 20:38 ` Segher Boessenkool @ 2020-10-24 17:06 ` Florian Weimer 2020-10-24 18:02 ` Segher Boessenkool 1 sibling, 1 reply; 8+ messages in thread From: Florian Weimer @ 2020-10-24 17:06 UTC (permalink / raw) To: mark_at_yahoo via Gcc-help * mark at yahoo via Gcc-help: > The necessity to add many of these pragmas makes the code difficult to > read. Is there a variable attribute that could be used instead, > something like: > char *buffer __attribute__((uninitialized)); In the past, this has been suggested as an official way to suppress the warning: char *buffer = buffer; See <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296#c3> for an example. It has the downside that it is almost certainly not valid C++ and probably not valid C, either. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __attribute__ to selectively disable -Wmaybe-uninitialized 2020-10-24 17:06 ` Florian Weimer @ 2020-10-24 18:02 ` Segher Boessenkool 0 siblings, 0 replies; 8+ messages in thread From: Segher Boessenkool @ 2020-10-24 18:02 UTC (permalink / raw) To: Florian Weimer; +Cc: mark_at_yahoo via Gcc-help On Sat, Oct 24, 2020 at 07:06:20PM +0200, Florian Weimer via Gcc-help wrote: > * mark at yahoo via Gcc-help: > > > The necessity to add many of these pragmas makes the code difficult to > > read. Is there a variable attribute that could be used instead, > > something like: > > char *buffer __attribute__((uninitialized)); > > In the past, this has been suggested as an official way to suppress the > warning: > > char *buffer = buffer; > > See <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296#c3> for an > example. > > It has the downside that it is almost certainly not valid C++ and > probably not valid C, either. It isn't valid C, see 6.3.2.1/2, last sentence (accessing a var when it is uninitialised, like the RHS of the assignment here does, is undefined behaviour). Yup. Segher ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-10-27 8:03 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <caf2f32f-3caf-fc89-0ca6-4c885a7b8ff1.ref@yahoo.com> 2020-10-23 20:01 ` __attribute__ to selectively disable -Wmaybe-uninitialized mark_at_yahoo 2020-10-23 20:38 ` Segher Boessenkool 2020-10-23 21:51 ` mark_at_yahoo 2020-10-24 8:49 ` J Decker 2020-10-24 18:32 ` Segher Boessenkool 2020-10-27 8:01 ` mark_at_yahoo 2020-10-24 17:06 ` Florian Weimer 2020-10-24 18:02 ` Segher Boessenkool
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).