Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: scoping vs linking Message-ID: <6762@brl-smoke.ARPA> Date: Mon, 30-Nov-87 11:20:23 EST Article-I.D.: brl-smok.6762 Posted: Mon Nov 30 11:20:23 1987 Date-Received: Thu, 3-Dec-87 04:06:56 EST References: <10575@brl-adm.ARPA> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 38 In article <10575@brl-adm.ARPA> ADLER1%BRANDEIS.BITNET@wiscvm.wisc.EDU writes: >routine1() >{ > char **klugev ; > routine2() ; >} >routine2() >{ > int i ; > char *s ; > klugev[i++] = s++ ; >} [Example abridged] >Everything works fine. It shouldn't have! >The compiler complained that it did not know what klugev is in routine2. That is what it should have done in any case. >Is there a way to tell routine2 that klugev is the variable introduced >in routine1 ? The simplest way is to pass it as a parameter to the function. It could also be moved outside routine1() as a global external datum. For information on how to do this, read Kernighan & Ritchie. >But then why did the program work in the first place ? I doubt that it really "worked". One contributing factor is that use of any identifier that has not been previously declared is assumed to be a reference to an external int datum. Apparently your linker used the "common" model and allocated storage for the (undefined) external int datum klugev. However, the compiler really should not have allowed subscripting of it by an integer... (Never rely on defaults like this but always declare identifiers before using them.)