using undeclared function returning bool results in wrong return value

using undeclared function returning bool results in wrong return value

[Thanos Makatos]

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.

Re: using undeclared function returning bool results in wrong return value

[Martin Sebor]

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.
> 

Re: using undeclared function returning bool results in wrong return value

[Jonathan Wakely]

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.

Re: using undeclared function returning bool results in wrong return value

[Florian Weimer]

* 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

Re: using undeclared function returning bool results in wrong return value

[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?

> So either use -Werror=implicit-function-declaration or C++ for the time
> being.
> 
> Thanks,
> Florian
> 
> 

Re: using undeclared function returning bool results in wrong return value

[Florian Weimer]

* 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

Re: using undeclared function returning bool results in wrong return value

[David Brown]

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

Re: using undeclared function returning bool results in wrong return value

[Jonathan Wakely]

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.

Re: using undeclared function returning bool results in wrong return value

[Jonathan Wakely]

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.

Re: using undeclared function returning bool results in wrong return value

[David Brown]

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" ?

Re: using undeclared function returning bool results in wrong return value

[David Malcolm]

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

Re: using undeclared function returning bool results in wrong return value

[David Brown]

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
> 

Re: using undeclared function returning bool results in wrong return value

[Martin Sebor]

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
> 

[PATCH] docs: add interactive vs batch distinction to UX guidelines

[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

Re: using undeclared function returning bool results in wrong return value

[Jonathan Wakely]

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.


>
>

Re: [PATCH] docs: add interactive vs batch distinction to UX guidelines

[David Malcolm]

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