* using undeclared function returning bool results in wrong return value @ 2021-02-17 21:05 Thanos Makatos 2021-02-17 22:05 ` Martin Sebor 2021-02-17 22:25 ` Jonathan Wakely 0 siblings, 2 replies; 16+ messages in thread From: Thanos Makatos @ 2021-02-17 21:05 UTC (permalink / raw) To: gcc I run into a problem that I'm not sure whether it's a bug in my program (most likely) or something wrong with GCC (highly unlikely, I know, hence why I haven't sent this to gcc-bugs). The problem is using a function that returns a bool, defined in another source file without a declaration, and the program compiled with -O. In my test, function foo1 returns true while it should be returning false. Here are the files and repro: /* main.c */ #include <stdio.h> #include <stdbool.h> #include <assert.h> bool foo2(int); void main(void) { assert(!foo2(0)); assert(!foo1(0)); } /* foo.c */ #include <stdbool.h> bool foo1(int n) { return n == 1 || n == 2 || n == 4; } bool foo2(int n) { return foo1(n); } # gcc --version gcc (Debian 8.3.0-6) 8.3.0 # gcc main.c foo.c -O In file included from main.c:3: main.c: In function 'main': main.c:9:10: warning: implicit declaration of function 'foo1'; did you mean 'foo2'? [-Wimplicit-function-declaration] assert(!foo1(0)); ^~~~ # ./a.out a.out: main.c:9: main: Assertion `!foo1(0)' failed. Aborted I get the same behavior if I use char instead of bool. The problem goes away if: 1. I declare foo1 in main.c (just like I do for foo2), or 2. compile w/o -O, or 3. use n == 3 instead of n == 4 in the return statement, or 4. use short or int instead of bool/char. Am I causing undefined behavior because I'm not declaring foo1? Please CC me in your response, I'm not subscribed to this list. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-17 21:05 using undeclared function returning bool results in wrong return value Thanos Makatos @ 2021-02-17 22:05 ` Martin Sebor 2021-02-17 22:25 ` Jonathan Wakely 1 sibling, 0 replies; 16+ messages in thread From: Martin Sebor @ 2021-02-17 22:05 UTC (permalink / raw) To: Thanos Makatos, gcc On 2/17/21 2:05 PM, Thanos Makatos via Gcc wrote: > I run into a problem that I'm not sure whether it's a bug in my program (most likely) or something wrong with GCC (highly unlikely, I know, hence why I haven't sent this to gcc-bugs). The problem is using a function that returns a bool, defined in another source file without a declaration, and the program compiled with -O. In my test, function foo1 returns true while it should be returning false. > > Here are the files and repro: > > /* main.c */ > #include <stdio.h> > #include <stdbool.h> > #include <assert.h> > > bool foo2(int); > > void main(void) { > assert(!foo2(0)); > assert(!foo1(0)); > } > > /* foo.c */ > #include <stdbool.h> > > bool foo1(int n) { > return n == 1 || n == 2 || n == 4; > } > > bool foo2(int n) { > return foo1(n); > } > > # gcc --version > gcc (Debian 8.3.0-6) 8.3.0 > # gcc main.c foo.c -O > In file included from main.c:3: > main.c: In function 'main': > main.c:9:10: warning: implicit declaration of function 'foo1'; did you mean 'foo2'? [-Wimplicit-function-declaration] > assert(!foo1(0)); > ^~~~ > # ./a.out > a.out: main.c:9: main: Assertion `!foo1(0)' failed. > Aborted > > I get the same behavior if I use char instead of bool. > > The problem goes away if: > 1. I declare foo1 in main.c (just like I do for foo2), or > 2. compile w/o -O, or > 3. use n == 3 instead of n == 4 in the return statement, or > 4. use short or int instead of bool/char. > > Am I causing undefined behavior because I'm not declaring foo1? Yes. Implicit function declarations are assumed to return int so defining one that doesn't match is undefined. If the function is defined to return a smaller type the value may be passed in only a part of a register (with the remaining bits left unchanged) and the caller will be looking at the whole thing. Martin > > Please CC me in your response, I'm not subscribed to this list. > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-17 21:05 using undeclared function returning bool results in wrong return value Thanos Makatos 2021-02-17 22:05 ` Martin Sebor @ 2021-02-17 22:25 ` Jonathan Wakely 2021-02-18 12:31 ` Florian Weimer 1 sibling, 1 reply; 16+ messages in thread From: Jonathan Wakely @ 2021-02-17 22:25 UTC (permalink / raw) To: Thanos Makatos; +Cc: gcc On Wed, 17 Feb 2021, 21:12 Thanos Makatos via Gcc, <gcc@gcc.gnu.org> wrote: > I run into a problem that I'm not sure whether it's a bug in my program > (most likely) or something wrong with GCC (highly unlikely, I know, hence > why I haven't sent this to gcc-bugs). This is the wrong list, please use gcc-help for questions like this. The problem is using a function that returns a bool, defined in another > source file without a declaration, and the program compiled with -O. In my > test, function foo1 returns true while it should be returning false. > As Martin explained, the compiler assumes that an implicitly-declared function returns an int. Your function initializes a single byte with its return value and the caller reads 4 bytes, including 3 bytes of uninitialized garbage. If that garbage happens to contains any non-zero bits, you get a non-zero int and converting that to bool yields true. Declare your functions. Don't ignore warnings. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-17 22:25 ` Jonathan Wakely @ 2021-02-18 12:31 ` Florian Weimer 2021-02-18 15:57 ` David Brown 0 siblings, 1 reply; 16+ messages in thread From: Florian Weimer @ 2021-02-18 12:31 UTC (permalink / raw) To: Jonathan Wakely via Gcc; +Cc: Thanos Makatos, Jonathan Wakely * Jonathan Wakely via Gcc: > Declare your functions. Don't ignore warnings. It's actually a GCC bug that this isn't an error. However, too many configure scripts would still break if we changed the default. So either use -Werror=implicit-function-declaration or C++ for the time being. Thanks, Florian ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-18 12:31 ` Florian Weimer @ 2021-02-18 15:57 ` David Brown 2021-02-19 8:45 ` Florian Weimer 0 siblings, 1 reply; 16+ messages in thread From: David Brown @ 2021-02-18 15:57 UTC (permalink / raw) To: Florian Weimer, Jonathan Wakely via Gcc; +Cc: Thanos Makatos On 18/02/2021 13:31, Florian Weimer via Gcc wrote: > * Jonathan Wakely via Gcc: > >> Declare your functions. Don't ignore warnings. > > It's actually a GCC bug that this isn't an error. However, too many > configure scripts would still break if we changed the default. > People have had 22 years to fix them. Implicit function declarations were a terrible idea from day 1, and banned outright in C99. It was reasonable for them to be accepted when the default C standard for gcc was "gnu90" - they should have never been acceptable in any later standards without needing an explicit flag. Since gcc 5 they have given a warning by default - surely it is time for them to be a hard error? > So either use -Werror=implicit-function-declaration or C++ for the time > being. > > Thanks, > Florian > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-18 15:57 ` David Brown @ 2021-02-19 8:45 ` Florian Weimer 2021-02-19 9:28 ` David Brown 0 siblings, 1 reply; 16+ messages in thread From: Florian Weimer @ 2021-02-19 8:45 UTC (permalink / raw) To: David Brown; +Cc: Jonathan Wakely via Gcc, Thanos Makatos * David Brown: > On 18/02/2021 13:31, Florian Weimer via Gcc wrote: >> * Jonathan Wakely via Gcc: >> >>> Declare your functions. Don't ignore warnings. >> >> It's actually a GCC bug that this isn't an error. However, too many >> configure scripts would still break if we changed the default. >> > > People have had 22 years to fix them. Implicit function declarations > were a terrible idea from day 1, and banned outright in C99. It was > reasonable for them to be accepted when the default C standard for gcc > was "gnu90" - they should have never been acceptable in any later > standards without needing an explicit flag. Since gcc 5 they have given > a warning by default - surely it is time for them to be a hard error? Have you actually tried to make the change and seen what happens? I fixed one bug in GCC less than two years ago because apparently, I was the first person trying to change the GCC default for real. This was actually my second attempt, this time using Jeff's testing infrastructure. The first attempt totally broke Fedora, so we gave up immediately and never even got as far as encountering the GCC bug. The second attempt got a little bit further, fixing bash, gawk, gettext, gnulib, make. Maybe that's all of GNU that needed fixing, but that seems unlikely (I didn't get through the full list of failing components). There were also many failures from other sources. Some looked rather hard to fix, for example unzip <https://bugzilla.redhat.com/show_bug.cgi?id=1750694>. In many cases key system components were affected where the upstream status is a bit dubious, so there is no good place for distributions coordinating their fixes and share the effort. This is just another thing that is unfixable in (GNU) C. Personally, I have stopped caring as long as the problem is not present in C++. Thanks, Florian ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-19 8:45 ` Florian Weimer @ 2021-02-19 9:28 ` David Brown 2021-02-19 11:18 ` Jonathan Wakely 0 siblings, 1 reply; 16+ messages in thread From: David Brown @ 2021-02-19 9:28 UTC (permalink / raw) To: Florian Weimer; +Cc: Jonathan Wakely via Gcc, Thanos Makatos On 19/02/2021 09:45, Florian Weimer wrote: > * David Brown: > >> On 18/02/2021 13:31, Florian Weimer via Gcc wrote: >>> * Jonathan Wakely via Gcc: >>> >>>> Declare your functions. Don't ignore warnings. >>> >>> It's actually a GCC bug that this isn't an error. However, too many >>> configure scripts would still break if we changed the default. >>> >> >> People have had 22 years to fix them. Implicit function declarations >> were a terrible idea from day 1, and banned outright in C99. It was >> reasonable for them to be accepted when the default C standard for gcc >> was "gnu90" - they should have never been acceptable in any later >> standards without needing an explicit flag. Since gcc 5 they have given >> a warning by default - surely it is time for them to be a hard error? > Just to be clear - I am not in any way suggesting that this situation is the fault of any gcc developers. If configure scripts are failing because they rely on poor C code or inappropriate use of gcc (code that requires a particular C standard should specify it - gcc has the "-std=" flags for that purpose), then the maintainers of those scripts should fix them. If Fedora won't build just because the C compiler insists C code is written in C, then the Fedora folk need to fix their build system. I appreciate that consistency and compatibility with existing, old and unmaintained code bases, configures and build systems is important. But the cost is that people continue to make the same mistakes they did before, they continue to write buggy code, and they continue to cause crashes, security holes, and other trouble. At least some problems could be stopped entirely by checks from tools like gcc. There is never going to be a catch-all "-Wbug-in-the-program" warning, but I really don't think it is unreasonable for a compiler to give an error on code that is considered so bad it is no longer supported by the language. The big problem I see is that as long as tools turn a blind eye (or at least a tolerant eye) to code faults in order to retain compatibility with older and poorer code bases, they let the same mistakes through in /new/ code. > Have you actually tried to make the change and seen what happens? > No - my comments are entirely wishful thinking. I realise the decisions for this kind of thing have to be made by people who /have/ tried it, and see the effects on a wide range of software - not by someone like me who uses gcc primarily for his own code. > I fixed one bug in GCC less than two years ago because apparently, I was > the first person trying to change the GCC default for real. This was > actually my second attempt, this time using Jeff's testing > infrastructure. The first attempt totally broke Fedora, so we gave up > immediately and never even got as far as encountering the GCC bug. The > second attempt got a little bit further, fixing bash, gawk, gettext, > gnulib, make. Maybe that's all of GNU that needed fixing, but that > seems unlikely (I didn't get through the full list of failing > components). There were also many failures from other sources. Some > looked rather hard to fix, for example unzip > <https://bugzilla.redhat.com/show_bug.cgi?id=1750694>. In many cases > key system components were affected where the upstream status is a bit > dubious, so there is no good place for distributions coordinating their > fixes and share the effort. > > This is just another thing that is unfixable in (GNU) C. Personally, I > have stopped caring as long as the problem is not present in C++. > I do understand that. I am not really expecting gcc to change its defaults here - the practicalities involve too much work. But it does not stop me /wanting/ a change, or believing the software world would be better for having such a change. David ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-19 9:28 ` David Brown @ 2021-02-19 11:18 ` Jonathan Wakely 2021-02-19 11:20 ` Jonathan Wakely 2021-02-20 14:25 ` David Brown 0 siblings, 2 replies; 16+ messages in thread From: Jonathan Wakely @ 2021-02-19 11:18 UTC (permalink / raw) To: David Brown; +Cc: Florian Weimer, Jonathan Wakely via Gcc, Thanos Makatos On Fri, 19 Feb 2021 at 09:42, David Brown wrote: > Just to be clear - I am not in any way suggesting that this situation is > the fault of any gcc developers. If configure scripts are failing > because they rely on poor C code or inappropriate use of gcc (code that > requires a particular C standard should specify it - gcc has the "-std=" > flags for that purpose), then the maintainers of those scripts should > fix them. If Fedora won't build just because the C compiler insists C > code is written in C, then the Fedora folk need to fix their build system. It's not Fedora's build system, it's the packages in Fedora's build systems. Lots of them. And those same packages are in every other Linux distro, so everybody needs to fix them. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-19 11:18 ` Jonathan Wakely @ 2021-02-19 11:20 ` Jonathan Wakely 2021-02-20 14:25 ` David Brown 1 sibling, 0 replies; 16+ messages in thread From: Jonathan Wakely @ 2021-02-19 11:20 UTC (permalink / raw) To: David Brown; +Cc: Florian Weimer, Jonathan Wakely via Gcc, Thanos Makatos On Fri, 19 Feb 2021 at 11:18, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > On Fri, 19 Feb 2021 at 09:42, David Brown wrote: > > Just to be clear - I am not in any way suggesting that this situation is > > the fault of any gcc developers. If configure scripts are failing > > because they rely on poor C code or inappropriate use of gcc (code that > > requires a particular C standard should specify it - gcc has the "-std=" > > flags for that purpose), then the maintainers of those scripts should > > fix them. If Fedora won't build just because the C compiler insists C > > code is written in C, then the Fedora folk need to fix their build system. > > It's not Fedora's build system, it's the packages in Fedora's build > systems. English makes that sentence ambiguous. What I mean is that it's the build systems (plural) of the packages (plural) in Fedora. Not the build system of Fedora. That isn't even written in C, it's mostly Python IIUC. > Lots of them. And those same packages are in every other > Linux distro, so everybody needs to fix them. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-19 11:18 ` Jonathan Wakely 2021-02-19 11:20 ` Jonathan Wakely @ 2021-02-20 14:25 ` David Brown 2021-02-20 15:46 ` David Malcolm 1 sibling, 1 reply; 16+ messages in thread From: David Brown @ 2021-02-20 14:25 UTC (permalink / raw) To: Jonathan Wakely, David Brown Cc: Florian Weimer, Jonathan Wakely via Gcc, Thanos Makatos On 19/02/2021 12:18, Jonathan Wakely via Gcc wrote: > On Fri, 19 Feb 2021 at 09:42, David Brown wrote: >> Just to be clear - I am not in any way suggesting that this situation is >> the fault of any gcc developers. If configure scripts are failing >> because they rely on poor C code or inappropriate use of gcc (code that >> requires a particular C standard should specify it - gcc has the "-std=" >> flags for that purpose), then the maintainers of those scripts should >> fix them. If Fedora won't build just because the C compiler insists C >> code is written in C, then the Fedora folk need to fix their build system. > > It's not Fedora's build system, it's the packages in Fedora's build > systems. Lots of them. And those same packages are in every other > Linux distro, so everybody needs to fix them. > It seems to me that there are two very different uses of gcc going on here. (I'm just throwing up some ideas here - if people think they are daft, wrong or impractical, feel free to throw them out again! I am trying to think of ways to make it easier for people to see that there are problems with their C or C++ code, without requiring impractical changes on large numbers of configuration files and build setups.) gcc can be used as a development tool - it is an aid when writing code, and helps you write better code. Here warnings of all sorts are useful, as it is better to find potential or real problems as early as possible in the development process. Even warnings about style are important because they improve the long-term maintainability of the code. gcc can also be used to build existing code - for putting together distributions, installing on your own machine, etc. Here flags such as "-march=native" can be useful but non-critical warnings are not, because the person (or program) running the compiler is not a developer of the code. This use is as a "system C compiler". Is it possible to distinguish these uses, and then have different default flags? Perhaps something as simple as looking at the name used to call the compiler - "cc" or "gcc" ? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-20 14:25 ` David Brown @ 2021-02-20 15:46 ` David Malcolm 2021-02-20 16:49 ` David Brown 2021-02-23 1:02 ` using undeclared function returning bool results in wrong return value Martin Sebor 0 siblings, 2 replies; 16+ messages in thread From: David Malcolm @ 2021-02-20 15:46 UTC (permalink / raw) To: David Brown, Jonathan Wakely Cc: Florian Weimer, Jonathan Wakely via Gcc, Thanos Makatos On Sat, 2021-02-20 at 15:25 +0100, David Brown wrote: > On 19/02/2021 12:18, Jonathan Wakely via Gcc wrote: > > On Fri, 19 Feb 2021 at 09:42, David Brown wrote: > > > Just to be clear - I am not in any way suggesting that this > > > situation is > > > the fault of any gcc developers. If configure scripts are > > > failing > > > because they rely on poor C code or inappropriate use of gcc > > > (code that > > > requires a particular C standard should specify it - gcc has the > > > "-std=" > > > flags for that purpose), then the maintainers of those scripts > > > should > > > fix them. If Fedora won't build just because the C compiler > > > insists C > > > code is written in C, then the Fedora folk need to fix their > > > build system. > > > > It's not Fedora's build system, it's the packages in Fedora's build > > systems. Lots of them. And those same packages are in every other > > Linux distro, so everybody needs to fix them. > > > > It seems to me that there are two very different uses of gcc going on > here. (I'm just throwing up some ideas here - if people think they > are > daft, wrong or impractical, feel free to throw them out again! I am > trying to think of ways to make it easier for people to see that > there > are problems with their C or C++ code, without requiring impractical > changes on large numbers of configuration files and build setups.) > > gcc can be used as a development tool - it is an aid when writing > code, > and helps you write better code. Here warnings of all sorts are > useful, > as it is better to find potential or real problems as early as > possible > in the development process. Even warnings about style are important > because they improve the long-term maintainability of the code. > > gcc can also be used to build existing code - for putting together > distributions, installing on your own machine, etc. Here flags such > as > "-march=native" can be useful but non-critical warnings are not, > because > the person (or program) running the compiler is not a developer of > the > code. This use is as a "system C compiler". I think there's an important insight here, in that there's a distinction between: (a) the edit-compile-debug cycle where the user is actively hacking on the code themself (perhaps a project they wrote, or someone else's), where they just made a change to the code and want to see what happens, as opposed to (b) a batch rebuild setting, where the user is recompiling a package, and GCC is a detail that's being invoked by a hierarachy of build systems (e.g. a Fedora mass rebuild that invokes koji, that invokes rpmbuild, that invokes some build tool, which eventually invokes gcc); perhaps a dependency changed, and the user is curious about what breaks (and hoping that nothing does, since they know nothing about this particular code, maybe they're just trying to get the distro to boot on some new architecture). I think we need to think about both of these use-cases e.g. as we implement our diagnostics, and that we should mention this distinction in our UX guidelines... > Is it possible to distinguish these uses, and then have different > default flags? Perhaps something as simple as looking at the name > used > to call the compiler - "cc" or "gcc" ? > ...but I'm wary of having an actual distinction between them in the code; it seems like a way to complicate things and lead to "weird" build failures. Thought experiment: what might a "--this-is-my-code" option do? Hope this is constructive Dave ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-20 15:46 ` David Malcolm @ 2021-02-20 16:49 ` David Brown 2021-02-23 2:26 ` [PATCH] docs: add interactive vs batch distinction to UX guidelines David Malcolm 2021-02-23 1:02 ` using undeclared function returning bool results in wrong return value Martin Sebor 1 sibling, 1 reply; 16+ messages in thread From: David Brown @ 2021-02-20 16:49 UTC (permalink / raw) To: David Malcolm, Jonathan Wakely Cc: Florian Weimer, Jonathan Wakely via Gcc, Thanos Makatos On 20/02/2021 16:46, David Malcolm wrote: > On Sat, 2021-02-20 at 15:25 +0100, David Brown wrote: > > I think we need to think about both of these use-cases e.g. as we > implement our diagnostics, and that we should mention this distinction > in our UX guidelines... > >> Is it possible to distinguish these uses, and then have different >> default flags? Perhaps something as simple as looking at the name >> used >> to call the compiler - "cc" or "gcc" ? >> > > ...but I'm wary of having an actual distinction between them in the > code; it seems like a way to complicate things and lead to "weird" > build failures. > Fair enough. > Thought experiment: what might a "--this-is-my-code" option do? > It should read the programmer's mind and tell them of any discrepancies between what they wrote and what they meant :-) I'd say it should make "-Wall" the default, and complain if "-std" is not specified explicitly, and if there is no "-O" flag (or a #pragma GCC optimise early in the code - even if it is an explicit -O0). That would cover things that I see people getting wrong regularly. (I am a big fan of explicit rather than implicit, and having default behaviour be a complaint that you are relying on default behaviour. But I may not be a typical user.) > Hope this is constructive > Dave > ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] docs: add interactive vs batch distinction to UX guidelines 2021-02-20 16:49 ` David Brown @ 2021-02-23 2:26 ` David Malcolm 2021-03-10 13:52 ` David Malcolm 0 siblings, 1 reply; 16+ messages in thread From: David Malcolm @ 2021-02-23 2:26 UTC (permalink / raw) To: David Brown, Jonathan Wakely Cc: Florian Weimer, Jonathan Wakely via Gcc, Thanos Makatos, David Malcolm On Sat, 2021-02-20 at 17:49 +0100, David Brown wrote: > > > On 20/02/2021 16:46, David Malcolm wrote: > > On Sat, 2021-02-20 at 15:25 +0100, David Brown wrote: > > > > > > I think we need to think about both of these use-cases e.g. as we > > implement our diagnostics, and that we should mention this > > distinction > > in our UX guidelines... > > > > > Is it possible to distinguish these uses, and then have different > > > default flags? Perhaps something as simple as looking at the > > > name > > > used > > > to call the compiler - "cc" or "gcc" ? > > > > > > > ...but I'm wary of having an actual distinction between them in the > > code; it seems like a way to complicate things and lead to "weird" > > build failures. > > > > Fair enough. [...snip...] How about the following addition to the User Experience Guidelines? gcc/ChangeLog: * doc/ux.texi: Add subsection contrasting interactive versus batch usage of GCC. --- gcc/doc/ux.texi | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/gcc/doc/ux.texi b/gcc/doc/ux.texi index fdba5da1598..28d5994d10f 100644 --- a/gcc/doc/ux.texi +++ b/gcc/doc/ux.texi @@ -86,6 +86,31 @@ information to allow the user to make an informed choice about whether they should care (and how to fix it), but a balance must be drawn against overloading the user with irrelevant data. +@subsection Sometimes the user didn't write the code + +GCC is typically used in two different ways: + +@itemize @bullet +@item +Semi-interactive usage: GCC is used as a development tool when the user +is writing code, as the ``compile'' part of the ``edit-compile-debug'' +cycle. The user is actively hacking on the code themself (perhaps a +project they wrote, or someone else's), where they just made a change +to the code and want to see what happens, and to be warned about +mistakes. + +@item +Batch rebuilds: where the user is recompiling one or more existing +packages, and GCC is a detail that's being invoked by various build +scripts. Examples include a user trying to bring up an operating system +consisting of hundreds of packages on a new CPU architecture, where the +packages were written by many different people, or simply rebuilding +packages after a dependency changed, where the user is hoping +``nothing breaks'', since they are unfamiliar with the code. +@end itemize + +Keep both of these styles of usage in mind when implementing diagnostics. + @subsection Precision of Wording Provide the user with details that allow them to identify what the -- 2.26.2 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] docs: add interactive vs batch distinction to UX guidelines 2021-02-23 2:26 ` [PATCH] docs: add interactive vs batch distinction to UX guidelines David Malcolm @ 2021-03-10 13:52 ` David Malcolm 0 siblings, 0 replies; 16+ messages in thread From: David Malcolm @ 2021-03-10 13:52 UTC (permalink / raw) To: David Brown, Jonathan Wakely Cc: Florian Weimer, Jonathan Wakely via Gcc, Thanos Makatos On Mon, 2021-02-22 at 21:26 -0500, David Malcolm wrote: > On Sat, 2021-02-20 at 17:49 +0100, David Brown wrote: > > > > > > On 20/02/2021 16:46, David Malcolm wrote: > > > On Sat, 2021-02-20 at 15:25 +0100, David Brown wrote: > > > > > > > > > > I think we need to think about both of these use-cases e.g. as we > > > implement our diagnostics, and that we should mention this > > > distinction > > > in our UX guidelines... > > > > > > > Is it possible to distinguish these uses, and then have > > > > different > > > > default flags? Perhaps something as simple as looking at the > > > > name > > > > used > > > > to call the compiler - "cc" or "gcc" ? > > > > > > > > > > ...but I'm wary of having an actual distinction between them in > > > the > > > code; it seems like a way to complicate things and lead to > > > "weird" > > > build failures. > > > > > > > Fair enough. > > [...snip...] > > How about the following addition to the User Experience Guidelines? I've gone ahead and pushed this to trunk (as c4a36bb1e1be0b826e71f4723c9f66266aa86b6f), after checking it bootstrapped. Dave > gcc/ChangeLog: > * doc/ux.texi: Add subsection contrasting interactive versus > batch usage of GCC. > --- > gcc/doc/ux.texi | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/gcc/doc/ux.texi b/gcc/doc/ux.texi > index fdba5da1598..28d5994d10f 100644 > --- a/gcc/doc/ux.texi > +++ b/gcc/doc/ux.texi > @@ -86,6 +86,31 @@ information to allow the user to make an informed > choice about whether > they should care (and how to fix it), but a balance must be drawn > against > overloading the user with irrelevant data. > > +@subsection Sometimes the user didn't write the code > + > +GCC is typically used in two different ways: > + > +@itemize @bullet > +@item > +Semi-interactive usage: GCC is used as a development tool when the > user > +is writing code, as the ``compile'' part of the ``edit-compile- > debug'' > +cycle. The user is actively hacking on the code themself (perhaps a > +project they wrote, or someone else's), where they just made a > change > +to the code and want to see what happens, and to be warned about > +mistakes. > + > +@item > +Batch rebuilds: where the user is recompiling one or more existing > +packages, and GCC is a detail that's being invoked by various build > +scripts. Examples include a user trying to bring up an operating > system > +consisting of hundreds of packages on a new CPU architecture, where > the > +packages were written by many different people, or simply rebuilding > +packages after a dependency changed, where the user is hoping > +``nothing breaks'', since they are unfamiliar with the code. > +@end itemize > + > +Keep both of these styles of usage in mind when implementing > diagnostics. > + > @subsection Precision of Wording > > Provide the user with details that allow them to identify what the ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-20 15:46 ` David Malcolm 2021-02-20 16:49 ` David Brown @ 2021-02-23 1:02 ` Martin Sebor 2021-02-23 7:47 ` Jonathan Wakely 1 sibling, 1 reply; 16+ messages in thread From: Martin Sebor @ 2021-02-23 1:02 UTC (permalink / raw) To: David Malcolm, David Brown, Jonathan Wakely Cc: Florian Weimer, Jonathan Wakely via Gcc, Thanos Makatos On 2/20/21 8:46 AM, David Malcolm via Gcc wrote: > On Sat, 2021-02-20 at 15:25 +0100, David Brown wrote: >> On 19/02/2021 12:18, Jonathan Wakely via Gcc wrote: >>> On Fri, 19 Feb 2021 at 09:42, David Brown wrote: >>>> Just to be clear - I am not in any way suggesting that this >>>> situation is >>>> the fault of any gcc developers. If configure scripts are >>>> failing >>>> because they rely on poor C code or inappropriate use of gcc >>>> (code that >>>> requires a particular C standard should specify it - gcc has the >>>> "-std=" >>>> flags for that purpose), then the maintainers of those scripts >>>> should >>>> fix them. If Fedora won't build just because the C compiler >>>> insists C >>>> code is written in C, then the Fedora folk need to fix their >>>> build system. >>> >>> It's not Fedora's build system, it's the packages in Fedora's build >>> systems. Lots of them. And those same packages are in every other >>> Linux distro, so everybody needs to fix them. >>> >> >> It seems to me that there are two very different uses of gcc going on >> here. (I'm just throwing up some ideas here - if people think they >> are >> daft, wrong or impractical, feel free to throw them out again! I am >> trying to think of ways to make it easier for people to see that >> there >> are problems with their C or C++ code, without requiring impractical >> changes on large numbers of configuration files and build setups.) >> >> gcc can be used as a development tool - it is an aid when writing >> code, >> and helps you write better code. Here warnings of all sorts are >> useful, >> as it is better to find potential or real problems as early as >> possible >> in the development process. Even warnings about style are important >> because they improve the long-term maintainability of the code. >> >> gcc can also be used to build existing code - for putting together >> distributions, installing on your own machine, etc. Here flags such >> as >> "-march=native" can be useful but non-critical warnings are not, >> because >> the person (or program) running the compiler is not a developer of >> the >> code. This use is as a "system C compiler". > > I think there's an important insight here, in that there's a > distinction between: > > (a) the edit-compile-debug cycle where the user is actively hacking on > the code themself (perhaps a project they wrote, or someone else's), > where they just made a change to the code and want to see what > happens, > > as opposed to > > (b) a batch rebuild setting, where the user is recompiling a package, > and GCC is a detail that's being invoked by a hierarachy of build > systems (e.g. a Fedora mass rebuild that invokes koji, that invokes > rpmbuild, that invokes some build tool, which eventually invokes gcc); > perhaps a dependency changed, and the user is curious about what breaks > (and hoping that nothing does, since they know nothing about this > particular code, maybe they're just trying to get the distro to boot on > some new architecture). > > I think we need to think about both of these use-cases e.g. as we > implement our diagnostics, and that we should mention this distinction > in our UX guidelines... > >> Is it possible to distinguish these uses, and then have different >> default flags? Perhaps something as simple as looking at the name >> used >> to call the compiler - "cc" or "gcc" ? >> > > ...but I'm wary of having an actual distinction between them in the > code; it seems like a way to complicate things and lead to "weird" > build failures. > > Thought experiment: what might a "--this-is-my-code" option do? I suspect any solution that relies on the user having to do something they don't already [know how to] do is going to be of help only to the negligible minority of advanced (or super careful) users. Those who would benefit from strict checking the most are typically not in that group. Not all build systems also make changing compiler command line options easy or even possible. So I wonder if changing configure to either implicitly use a command line option for its tests or set an environment variable to request a permissive mode might be a way out. Martin > > Hope this is constructive > Dave > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: using undeclared function returning bool results in wrong return value 2021-02-23 1:02 ` using undeclared function returning bool results in wrong return value Martin Sebor @ 2021-02-23 7:47 ` Jonathan Wakely 0 siblings, 0 replies; 16+ messages in thread From: Jonathan Wakely @ 2021-02-23 7:47 UTC (permalink / raw) To: Martin Sebor Cc: David Malcolm, David Brown, Florian Weimer, Jonathan Wakely via Gcc, Thanos Makatos On Tue, 23 Feb 2021, 01:02 Martin Sebor, <msebor@gmail.com> wrote: > > So I wonder if changing configure to either implicitly use a command > line option for its tests or set an environment variable to request > a permissive mode might be a way out. > Having a different set of rules for configure scripts is bound to fail at some point. The obvious example is a configure check to see if functions with implicit prototypes can be called. That would work in permissive mode, but fail when trying to run the compiler later. > > ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-03-10 13:52 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-17 21:05 using undeclared function returning bool results in wrong return value Thanos Makatos 2021-02-17 22:05 ` Martin Sebor 2021-02-17 22:25 ` Jonathan Wakely 2021-02-18 12:31 ` Florian Weimer 2021-02-18 15:57 ` David Brown 2021-02-19 8:45 ` Florian Weimer 2021-02-19 9:28 ` David Brown 2021-02-19 11:18 ` Jonathan Wakely 2021-02-19 11:20 ` Jonathan Wakely 2021-02-20 14:25 ` David Brown 2021-02-20 15:46 ` David Malcolm 2021-02-20 16:49 ` David Brown 2021-02-23 2:26 ` [PATCH] docs: add interactive vs batch distinction to UX guidelines David Malcolm 2021-03-10 13:52 ` David Malcolm 2021-02-23 1:02 ` using undeclared function returning bool results in wrong return value Martin Sebor 2021-02-23 7:47 ` Jonathan Wakely
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).