🚀 go-pugleaf

In article <12DEC199222504264@eql.caltech.edu>, rankin@eql.caltech.edu (Pat
Rankin) writes:

|>In article <Bz5M1C.Kns@dscomsa.desy.de>, Hallam@zeus02.desy.de writes...
|>> There is a difference in the behaviour of the C compiler, The VAX compiler
|>> was lax about insisting that extern variables be declared at some point
|>> (ie without the extern part).
|>
|>     There is a CC qualifier available for controlling the model used for
|>extern objects.  You can get behavior identical to VAX C's by using it.
|>
|>> Bit of a silly C feature I think, a declaration should be a declaration.
|>
|>     A declaration is not a definition, and the old sloppy code was what
|>was silly (for C; it matched the FORTRAN common block behavior).  The
|>method used as the default by DEC C is sanctioned by the C standard.  If
|>you argue that /standard=vaxc ought to imply /extern_model=common_block
|>for better VAX C compatibility then I might agree with you, but the
|>current default is more appropriate for ANSI mode.  There is also a
|>#pragma directive for controlling this on a case-by-case basis.

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