🚀 go-pugleaf

In article <Bz85qD.79F@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
|>Perhaps if they had mentioned the change in the manual... The problem is that
|>the diffs for AXP manual only lists the differences of that compiler running on
|>the AXP as opposed to VAX. They do not mention the differences between the VAX C
|>and DEC C on VAX...
|>
|>Unless they provide some form of check to ensure that external references are to
|>the same type at every point I fail to see any value in this change. If I wanted
|>a compiler to give me type checking information that makes it refuse to produce
|>an object I would not be using C. I really cannot see a bug that this system
|>could catch, that should be the test.
|>
|>Still, ANSI have been buggering up languages with silly standards since the
|>pascal fiasco where they defined vectors of length 3 as being incompatible with
|>those of length 4 making it impossible to write a string handling routine or
|>general matrix multiplication routine in ANSI standard Pascal.
|>
|>The reason why I am moving data about via pseudo common blocks is not "sloppy"
|>code. It is becuase I am producing routines using a preprocessor and do not want
|>the user to have to know what data is being exported to the run time library, in
|>fact I don't want them to know that they are exporting data...
|>
|>The type definitions are themselves produced by a preprocessor, this restriction
|>now subjects what was a very nicely symetrical system to preprocessor hackery.
|>
|>Phill Hallam-Baker

The ANSI C Document, RATIONALE Section 3.1.2.2 "Linkages of identifiers"
actually explains that they inidicated that external linkage was "a major
standardization issue". This section explains very well why this was a problem
and the reason it is done the way it is  done. It is not silly or unreasonable,
but a good policy to enforce proper typing and control where the acutal
storage definition occurs, and scoping problems involved with linkage.

The short form is that ANSI C is that "extern" indicates a pure reference
which does not define storage, and only one definition is allowed.
----------------------------------------------------------------------------
Dwight D. Moore
Geosciences Computing Network
University of Oklahoma

dwight@geohub.gcn.uoknor.edu (129.15.40.10)
These opinions do not necessarily represent the opinions of OU or the GCN.
----------------------------------------------------------------------------