I have a heads up report which I have to make in this form because it's
not repeatable. I am sometimes getting errors that, when I try
creating sample programs to repeat them, first I will get a problem,
then sometimes if I add comments, all of a sudden the problem vanishes
and I get clean compiles that do work. I'm not sure exactly what is
happening, because sometimes I can get the problem to repeat itself
consistently, but then I check to see and the problem is no longer
I was trying to produce a reproducible bug and in 4 cases, the bug would
disappear and the (sample) programs would then compile correctly.
So there is something which, at the moment, I can't quite put my finger
Where the issue is, is in another program I'm trying to compile and
getting spurious errors.
I have a relatively large program (7028 lines) which is comiing up as
being too short; FPC thinks when the program reaches END. that there
should still be more code present.
This program compiles successfully with the Australian Atomic Energy
Commission (AAEC) Pascal Compiler for the IBM 370 Mainframe. Which it
should, as it turns out, the program *IS* the AAEC Pascal compiler.
(It's obviously a much simpler version of Pascal than that supported by
I've tracked the problem down to one specific nested procedure in that
if I put a BEGIN END; BEGIN END. before this one procedure it does a
clean compile. Putting them after this one procedure causes the
compiler to think the program is too short. I put count marks on all
of the BEGIN END pairs and it balances correctly. So I can't quite
figure out what is wrong.
Perhaps the program is exceeding the maximum number of nested
I've been doing a translation on it to try and compile it on FPC to see
how it would work. (Also to give me ideas on how to port FPC over to
the IBM 370 which is my eventual intent.) AAEC seems to do a bang-up
job of putting stress on FPC in ways I haven't seen before and allowing
me to discover just how strong the FPC compiler is, in the ways it
enforces strict type checking and other issues and to a degree may make
programs more documenting.
I get wierd errors in different ways that aren't always consistent.
When trying to isolate the problems, in some cases I can repeat the
problem and other times I can't. Currently the only one I am
consistently getting is that FPC thinks the AAEC Compiler source is too
short, and it also (sometimes) doesn't like a pointer issue, but when I
try reproducing the pointer problem as another program, first it gave
an error the same way, then it stopped giving errors and reported the
small program as compiling correctly. I'm not sure if there is an
issue with the IDE that is used under Windows.
It could be that there is a problem with the size of the generated
program. But it does use lots of procedures so it shouldn't create a
very large procedure.
I suspect there could be a problem with comments in programs, especially
the use of the old fashioned (* and *) format. Sometimes the use of a
construct such as (********************) or something similar may cause
spurious errors, but sometimes it doesn't have a problem and I'm not
sure why. There may be a problem with the * character embedded in a (*
I know this is a bit of a frustrating (pseudo-) bug report, but it's a
frustrating problem which isn't consistent. The problem could also be
that the generated program is exceeding some limit in FPC in different
ways and causing spurious errors as a result.
I think the next step is to take this program and break it into units,
which might help solve the problem. If I can better isolate the issue
and get a repeatable condition I'll report it once I can get the error
to manifest itself.
> I know this is a bit of a frustrating (pseudo-) bug report, but it's a
> frustrating problem which isn't consistent. The problem could also be
> that the generated program is exceeding some limit in FPC in different
> ways and causing spurious errors as a result.
> I think the next step is to take this program and break it into units,
> which might help solve the problem. If I can better isolate the issue
> and get a repeatable condition I'll report it once I can get the error
> to manifest itself.
Without sourcecode we can't verify or debug the problem.