Implicit function declarations and GCC 10

[Florian Weimer]

* Segher Boessenkool:

> Hi Florian,
>
> On Fri, Jul 05, 2019 at 07:49:21AM +0200, Florian Weimer wrote:
>> > We already have an option for that (-Werror=implicit-function-declaration),
>> > and it is an error by default with -pedantic-errors already.  If you are
>> > asking to make it an error by default, I second that; there needs to be a
>> > wat to turn it off though.  Maybe it should be an error for c99 and later
>> > only, anyway?
>> 
>> Yes, it should be an error by default, without any flags.  Which is
>> gnu11 mode by now, I think.  So it's not sufficient to do this for
>> c99/c11 mode.
>
> When I say "c99 and later", of course that includes gnu99 and gnu11.  My
> point is that we probably shouldn't by default error on this in c90 mode,
> since it is a valid construct there, and not extraordinarily harmful.

Ah, sorry.  Yes, this isn't for c90 mode.  I'm less concerned with
programmers who set -std=, they can use
-Werror=implicit-function-declaration as well if they want.  It is
really the flag-less default that matters to me.

>> >> According to my observations, lack of an error diagnostic has turned
>> >> into a major usability issue.  For bugs related to pointer truncation,
>> >> we could perhaps change the C front end to produce a hard error if an
>> >> int value returned from an implicitly declared function is converted to
>> >> a pointer.
>> >
>> > No, if we allow implicit declarations at all, your proposal would error
>> > on valid (but improbable :-) ) code.  We should only ever give hard
>> > errors if we *know* something is wrong.
>> 
>> Yes, it should be valid code on 32-bit targets, which is why it's so
>> common.
>
> It is valid for *all* targets.  C11 6.3.2.3/5:
>   An integer may be converted to any pointer type. Except as previously
>   specified, the result is implementation-defined, might not be correctly
>   aligned, might not point to an entity of the referenced type, and might
>   be a trap representation.
>
> and GCC documents that implementation-defined behaviour as
>   A cast from integer to pointer discards most-significant bits if
>   the pointer representation is smaller than the integer type,
>   extends according to the signedness of the integer type if the
>   pointer representation is larger than the integer type, otherwise
>   the bits are unchanged.

What I meant is that this works just fine on 32-bit architectures
because there is no truncation involved.

>> >> Implicit int we should remove as well.  Checking configure scripts for
>> >> both issues at the same time would not be much more work.
>> >
>> > We could enable -Wimplicit-int by default for c99 and later, maybe even
>> > its -Werror- version.  This conflicts with at least -fms-extensions it,
>> > seems, dunno what to do there.
>> 
>> We can keep this a separate discussion if it helps.
>
> Yes please.  Can you make separate PRs?  There is essentially no
> overlap.

I filed PR91092 and PR91093.

Thanks,
Florian