Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!tikal!hplsla!hpvcla!neff
From: neff@hpvcla.HP.COM (Dave Neff)
Newsgroups: comp.lang.pascal
Subject: Re: Odd behaviour of Microsoft Pascal 3.31
Message-ID: <4900001@hpvcla.HP.COM>
Date: Tue, 11-Aug-87 15:26:48 EDT
Article-I.D.: hpvcla.4900001
Posted: Tue Aug 11 15:26:48 1987
Date-Received: Sat, 15-Aug-87 05:23:27 EDT
References: <473@clinet.FI>
Organization: Hewlett Packard, Vancouver, WA
Lines: 38

This is a known bug in Microsoft Pascal. I have seen it too and have
called Microsoft about it.  The strange "fixes" have to do with the
fact that the problem is apparently related to the contents of normally
"unused" memory that the confused compiler starts using.  Hence depending upon
the state of the memory you may not always see the problem.  The code
generated seems O.K. but it is a bit scary!

I believe the easiest way to reproduce the problem is by passing a
function returning a real as a function parameter to a procedure (if
my foggy memory serves me correctly).  It may even just be passing
function parameters in general.  When I changed the function parameter to a
procedure (with the "function" result as a VAR parameter) this bug
went away.

You can also see similar or stranger behavior as the compiler "comes close"
to running out of memory.  If you have many global types/variables or
a very large source file there is a situation in which you don't see
the dreaded "compiler out of memory" error but instead the compiler
will spit out one syntax error message on a line which has
perfectly good syntax!  This one is really baffling when you see it.
If you can reduce the number of global types and/or module size the
problem goes away.  I generally run EXEMOD on the compiler (PAS1) to up its
stack size  by a few K.  This generally will let the compiler process
more complex source code but beware: doing this tweak will sometimes
result in compiling a more complicated source but failing to compile
(compiler out of memory) one which previously compiled.  I sure wish
this supposedly "pro" compiler would use all of available memory for
its symbol tables rather than its current static approach. It presently has a
static table of pointers to symbols.  Some of this data (i.e. identifier
names) is outside of the 64K data segment but the table of pointers is not.

About 2 weeks ago Microsoft sent me a free upgrade for the compiler
(version 3.32) which fixes some unspecified minor bugs.  You should probably
contact Microsoft and get the new compiler.  Perhaps it fixes the
bugs you have been seeing.

Dave Neff
ihnp4!hpfcla!hpvcla!neff