Peter N Lewis wrote:
At 0:05 +0200 14/10/04, Adriaan van Os wrote:
--ignore-garbage-after-dot Ignore anything after the terminating '.' (default in '--borland-pascal').
So, this looks like a preprocessor problem.
It's not just a preprocessor problem, other things get noticed after the end. as well.
Eg:
A single open comment ({ or (*) will generate an unterminated comment error
Unmatched string characters (" or ') will generate errors unterminated string or character constant and possible real start of unterminated constant. So for example:
<snip>
All that is handled by the preprocessor.
And presumably other such things. I'm used (from my CodeWarrior time and other compilers) to chucking comments and old code, snippets, data, after the "end." but it does not work very well with GPC. With GPC I typically (* comment the stuff at the end after the end. since I normally use {} or // comments, but of course if the snippets of code have (**) comments in them this screws it up, and I have to go mangle them.
I understand why this may be tricky if the file is pre-parsed and the pre-parser doesn't notice the "end." symbol combination (though presumably it could, since presumably that is not ambiguous, there isn't any other case where that pair of symbols is legal is there?), so I'd be happy with something akin to Perl's "__END__" marker to stop the pre-processor/pre-parser at that point, then I could just have:
end. __END__ random { ' text
Note that you can use:
{$if 0} balanced text {$endif}
and the preprocessor will skip `balanced text'. You can not put any garbage there, the comments in balanced text still have to match... But as long as you want to mix normal text with correct Pascal you should be able to nest such constructs arbitrarily.