Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Good.  The above code is nonsense, the chances that foo will be
>> incorrectly called are high.
>
> Yet lint (or scrutiny, as should be performed with any declaration,
> implicit or not) makes sure that does not happen.

Relying on human scrutiny when an algorithm can trivially deduce an
answer more quickly and more reliably (because even in the case that the
code you showed compiles, it assumes processor specific facts) has
historic precedent as being a bad idea.

I'm curious, though, about how lint checks for this.

>> What is this meant to produce?
>
> It was just an example.  I'm not allowed to show any real code.
>
>> This is, at best, a "works by coincidence", rather than being code
>> anyone should be writing.
>
> See what I said about being the judge, jury and executioner.
>
>   (BTW, I thought implicit int was being discussed, not implicit
>    function declarations, but here goes.)
>
> The same problems will appear with _any_ extern declaration.  If you
> remove implicit function declarations, people will simply paste:
>
>   extern int foo ();
>
> above the code which no longer compiles.
> Or, if you force everyone to use prototypes,
>
>   extern int foo (char *);

So be it.  The edge case still exists.  The normal case that I expect
most code is dealing with is much simpler: a missing include.  That case
is not discounted by the existence of misdeclarations across TUs.

> You will not be able to diagnose whether or not this declaration is
> correct, because the definition will lie in another translation unit.
> Except that in this case, no diagnostic will be issued at all when
> the declared function is called.
>
> The only place where you can truly fix mismatched declarations is the
> linker (or collect2?)  GCC proper cannot do anything about it.

There's already -Wlto-type-mismatch.  It has spotted a few bugs in my
own code.

>> Such code is already written, when building it, pass -fpermissive.
>> You benefit from the error otherwise.
>>
>> (and no, this isn't an issue of style, the code in question *does not*
>> convey sufficient information for the compiler to always do the right
>> thing)
>
> It does on reasonable machines for which the code was written.  I gave
> two examples.  Perhaps the 386 is another.

Yes, indeed.  And code should keep working on those machines, because it
costs little to nothing to keep it working.  And it will if you pass
-fpermissive.

It seems to me plausible that the paragraph in the original proposal
that suggested -fpermissive might have been missed.

It is unfeasible for GCC to entirely stop compiling this code, there's
nobody that is advocating for doing that; however, the current default
of accepting this code in C is harmful to those who are writing new
code, or are learning C.

This seems like a good route to me - it facilitates both veterans
maintaining code and beginners just learning how to write C.

Have a lovely day.
-- 
Arsen Arsenović