msa@clinet.FI (Markku Savela) (08/06/87)
I have been using Microsoft Pascal (version 3.31) for a program which consists of several (25-40) modules. I'm using the INTERFACE/IMPLEMENTATION sections. The final code takes about 200-300Kb. Occasionally I run into very disturbing behaviour in the compiler. After some minor changes into modules, compiler suddenly decides, that one or another module won't compile. Some final error messages are: "Error: Compiler Invalid Pointer Range" (and usually followed by "Null Pointer Assignment") or "Error: Compile Pointer To Disposed Var" The above are often preceded by several reports of non-existent syntax errors. The funny thing is that I may get the compilation to succeed without errors using some of the following tricks: - move all files to another PC/AT and compile them there - ask pascal listing file (xxx.LST) - add dummy "CONST"-declarations to the module (e.g. dummy1 = 123;) (this is the most sure way, but it takes time to hit the right combination -- does anyone have an algorithm for the combination?) Is this a feature of my special brand of PC/AT "clone" (NOKIA ASC, MS-DOS 3.1, Phoenix Bios) or is Microsoft Pascal broken in some way? -------------- Markku Savela Nokia Information Systems P.O.BOX 780 SF-00101 HELSINKI, FINLAND uucp: msa@clinet.UUCP
neff@hpvcla.HP.COM (Dave Neff) (08/11/87)
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