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

[David Malcolm <dmalcolm@redhat.com>]

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