Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!mcnc!decvax!ucbvax!ucbcad!tektronix!hplabs!sri-unix!DBrown@Hi-Multics.ARPA
From: DBrown@Hi-Multics.ARPA
Newsgroups: net.unix-wizards
Subject: is "extern" ambiguous
Message-ID: <426@sri-arpa.UUCP>
Date: Thu, 29-Mar-84 15:13:00 EST
Article-I.D.: sri-arpa.426
Posted: Thu Mar 29 15:13:00 1984
Date-Received: Tue, 3-Apr-84 20:10:00 EST
Lines: 100

From:      Dave Brown <DBrown@Hi-Multics.ARPA>

  There  is  a  difficulty  (I  won't call  it  a  bug)  with the
understanding  that  PCC  and  Lint  have  of  what  "extern" and
"static" mean.
  We have several programs obtained from a Vax site which contain
code like:

  <beginning of file>
  main () {
          extern int proc1();

          ...
          proc1();
          ...
  }

  static proc1() {
          ...
  }
  <end of file>


  PCC and Lint notice the  "extern" declaration and remember that
the  author  has  warned them  that  they  may have  to  issue an
external reference.   They then find  the procedure in  the file,
decide that they can link it  without issuing an external ref for
LD, and quite properly do so.

  Unfortunatly, at this point they seem to have lost track of the
fact  that the  first declaration asserted  something that wasn't
true:  it  claimed that proc1  was a "normal"  external function.
We now see  that proc1 isn't a normal external,  but instead is a
"static" (meaning private) function.
  To quote  the white book,  "..  static variables  and functions
provide a way  to conceal data objects and  any internal routines
that  manipulate  them so  that  other routines  and  data cannot
conflict even inadvertantly."
  For obvious reasons we prefer to have the function declared the
same way (as static) every time,  and have redeclared it that way
so Lint won't complain so loudly.

  This raises two questions:
   (1)  Does  anyone have  a  compiler which  DEMANDS  statics be
predeclared as externs?  (ie, can  we fix the code without making
that a machine- or compiler-specific fix), and
   (2) Are  the Unix(tm) compilers and  Lint correct in accepting
this construct  or should they  be regarding this as  a legal but
non-portable construct?

  --dave (unix hack on a bun) brown
  There  is  a  difficulty  (I  won't call  it  a  bug)  with the
understanding  that  PCC  and  Lint  have  of  what  "extern" and
"static" mean.
  We have several programs obtained from a Vax site which contain
code like:

  <beginning of file>
  main () {
          extern int proc1();

          ...
          proc1();
          ...
  }

  static proc1() {
          ...
  }
  <end of file>


  PCC and Lint notice the  "extern" declaration and remember that
the  author  has  warned them  that  they  may have  to  issue an
external reference.   They then find  the procedure in  the file,
decide that they can link it  without issuing an external ref for
LD, and quite properly do so.

  Unfortunatly, at this point they seem to have lost track of the
fact  that the  first declaration asserted  something that wasn't
true:  it  claimed that proc1  was a "normal"  external function.
We now see  that proc1 isn't a normal external,  but instead is a
"static" (meaning private) function.
  To quote  the white book,  "..  static variables  and functions
provide a way  to conceal data objects and  any internal routines
that  manipulate  them so  that  other routines  and  data cannot
conflict even inadvertantly."
  For obvious reasons we prefer to have the function declared the
same way (as static) every time,  and have redeclared it that way
so Lint won't complain so loudly.

  This raises two questions:
   (1)  Does  anyone have  a  compiler which  DEMANDS  statics be
predeclared as externs?  (ie, can  we fix the code without making
that a machine- or compiler-specific fix), and
   (2) Are  the Unix(tm) compilers and  Lint correct in accepting
this construct  or should they  be regarding this as  a legal but
non-portable construct?

  --dave (unix hack on a bun) brown