Skip to content

Final end preceded by nearby comment which then causes the compiler to ignore the END . and produces erroneous END OF FILE error.

Summary

A pair of closed comments cause the compiler to miss the last "END ." and erroneously claim end of file error.

System Information

  • Operating system:

    64-bit Windows 10 Pro 10.0 build 19045

  • Processor architecture:

    x86-64

  • Compiler version:

    Lazarus 2.2.6 using FPC Version 3.2.2

  • Device:

    Desktop computer

Steps to reproduce

In a Pascal program from 1978, when corrected for errors of procedure calling sequences mandatory then but prohibited now, and removing a non-standard feature, replacing it with a similar existing feature, and getting to the end, FPC claims premature end of file. I restructured the code in that section to make even left spacing and indenting on encapsulating items (BEGIN-END; FOR; WHILE-REPEAT) I confirm the code is correct. So I use the "trap and catch" method of discovering an error. I find a spot outside a block and using one or more end statement followed by a space and period, I get a clean, green line ok from the compiler. So I dike that added item out with // (so I have a record of where I did a compiler trap) and move forward a handful of lines, lather, rinse, repeat. Finally, i am at the bottom of the program, which looks like this:

(*6562*)END

(*6563*) END;

(*6564*){* $L+*)

(*6565*) END .

Example Project

I tried this, creating a small test program to duplicate this but could not repeat the behavior.

What is the current bug behavior?

Compiler erroneously reports end of file after passing over "END ,"

What is the expected (correct) behavior?

Compiler reports compile was successful.

Relevant logs and/or screenshots

The program is too large to post here - about 6,700 lines - so I have created a public repository on Github: https://github.com/electric-socket/pascal8000/ and the relevant files (that I was using with FPC) are the ones named AAEC_COMPILER (.lpi, .lps, .pas). The unchanged original is there as Pascal8000LinkEdit.pas. The reason I know this program works is that it is the Pascal 8000 compiler for IBM mainframes, and running the original through itself on the Hercules mainframe emulator running TK5 MVS operating system, gets a flawless compile.

The only reason I'm pointing this out is that it is clearly an error, a double old-style comment faults the FPC compiler. I can't think of anything else.

Possible fixes

As shown on the example above - and those numbered comments were not decorations, but line numbers. When a compiler goes through all ~6,562 lines and reports it failed, you start to wonder. However, if the above is changed to

(*6562*)END

(*6563*) END;

// (*6564*){* $L+*)

(*6565*) END .

The compiler repots success. Compiles flawlessly. Removing " $L+" makes no difference. So I believe it has to be the two comments near each other are confusing FPC.

Edited by Paul Robinson
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information