From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10737 invoked by alias); 30 Aug 2015 16:50:16 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 10706 invoked by uid 48); 30 Aug 2015 16:50:12 -0000 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/67386] missing diagnostic on a use of an undeclared function Date: Sun, 30 Aug 2015 16:50:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 5.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-08/txt/msg02065.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67386 --- Comment #3 from Martin Sebor --- >>From Doug Gwyn's response on the WG14 list about the C90 wording with respect to the placement of the implicit declaration (quoted below) it seems that even though diagnosing line 11 in f2() in comment #2 goes against a strict interpretation of the C90 rule, it is in the spirit of the original K&R C and the consequences of the strict interpretation may not have been intended. After thinking about it some more, it doesn't seem worthwhile to open a new bug for this. It would likely and up getting closed as WONTFIX anyway since changing the behavior would only serve to break legacy code. >> ... But again, I'm surprised to find that some compilers inject it just > before the call >> to the function, while others inject it "at the top of the block." >> The former compilers then issue an error for the first reference to foo > below: >> void bar (int i, int (*p)(int)) { >> p = foo; /* valid? */ >> i = foo (i); >> } > > One could reasonably argue that the "top of the block" compilers more > accurately > implement the C90 wording; however, Ritchie's PDP-11 C compiler (which I > continue to > enhance and maintain) enacts an implicit declaration of "foo" (as an extern > int in this > example) at the first place it is seen, and therefore issues an error for > the second, > incompatible occurrence. This compiler was designed to be pretty much > "one pass".