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.)