The gpc manual states:
--ignore-garbage-after-dot Ignore anything after the terminating ‘.’ (default in ‘--borland-pascal’).
However, the following testprogram:
{$ignore-garbage-after-dot} program Test; begin end. blabla #include <sys/types.h>
results in:
garbage.p:6: no include path in which to find sys/types.h
So, this looks like a preprocessor problem.
Regards,
Adriaan van Os
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:
**** end.
Enough, I'm through with this program! ****
will generate an error.
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 ****
Enjoy, Peter.
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.
At 5:25 +0200 14/10/04, Waldek Hebisch wrote:
Note that you can use:
{$if 0} balanced text {$endif}
It's a good suggestion, but it doesn't really solve the problem. That remains "ignore-valid-pascal-after-dot" which the current compiler flag handles. It is the "garbage" (particularly not-Pascal stuff) that I want to ignore that is a challenge. The "garbage" is often free form text, code from other languages, original data or workings, as well as "commented out" Pascal code.
Enjoy, Peter.
Waldek Hebisch wrote:
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.
Indeed. The compiler recognizes `end.', but the preprocessor doesn't.
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?),
Generally not AFAICS, but there's a tricky case with interface and implementation modules in one file (where the first `end.' terminates the interface module).
It could probably be done, but since I plan to integrate the preprocessor into the compiler, anyway, (to fix other problems and simplify things vastly), I don't really feel like doing it now. If you want to, just go ahead, of course ...
Frank
-
Adriaan van Os -
Frank Heckenbach -
Peter N Lewis -
Waldek Hebisch