Forum > General

inconsistent treatment of "end."

(1/5) > >>


In Pascal, the presence of "end." tells the compiler that it has reached the end of the source code, therefore should _not_ attempt to compile anything that follows those two tokens.  FPC behaves strangely in some cases depending on what follows the "end."

Consider the following program
--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---program endeof; beginend.      { all text after "end." should be ignored as "end." marks the end of            the pascal source code }  // #include <stdio.h>    // UNCOMMENT this line and recompile                         // it doesn't like the #  // open brace and pound sign are two characters it doesn't like after "end."// also the other opening comment (* is unwelcome // #// {// (* but no complaints at all about this stuff include <stdio.h> ...... almost any text you want hereand here too while true do ignore all text procedure hereweare and ignored  As it is, the program will compile but, uncommenting the #include will cause an error as will uncommenting the lines that have the #, the { or the (*

for some reason there are some things it is not ignoring.

For the record, Delphi ignores everything after the "end." but will emit a warning cautioning that the text after "end." was ignored.

Useful comments welcome.

I feel this is possibly a regression: lots of times I add  C code after end. when I translate a piece of C or C++ and I can't remember it was like this. I should have encountered it.

if I recall correctly, v3.0.4 did it too but, I was focused on translating the C code and forgot to report the problem.

This time, I figured I'd stop porting code and report it because occasionally, depending on the C code, it can get really annoying.

Ah, I see why I never encountered it: I put my C code between (* and *). Of course then you will never notice it... I did not realize I was so consistent with that.

I do that too but, if the code uses pointer typecasts such as (typename*) then the last two characters of the typecast close the Pascal comment which often exposes other characters FPC is unhappy with.

For reasonably simple stuff bracketing the C code between (* and *) works but, when pointer typecasts are present, it often ends up not working.

For the same reason using "{" and "}" is even worse because encountering another "{" in the C code is basically a certainty.


[0] Message Index

[#] Next page

Go to full version