While working on a MacPascal dialect to GPC porting project, I was surprised to encounter preprocessor errors in conditional compilation directives where the conditional expression directly or indirectly (i.e., a macro expansion) contained $ hex constants. A short example (thanks Afriaan):
program dollars; {$definec dollars $1} {$ifc dollars = 1} {$endc} begin end.
Compiling yields the error:
dollars.pas:3: conditional expression: parse error
If one changes {$definec dollars $1} to {$definec dollars 1}, it compiles with no problem.
After some futher testing and digging into the gpcpp.c source code, it looks like the preprocessor doesn't support $ hex constants in conditional expressions for conditional compilation directives.
Since $ hex constant usage in preprocessor expressions (including conditional compilation directives) has been supported in MacPascal dialect compilers for well over two decades and it has been a long standing "standard" to use hex nibble formatting convensions for things such as conditional compilation version testing, the lack of GPC preprocessor support for $ hex constants in preprocessor conditional expressions creates MacPascal to GPC code porting problems. (Note: I'm not sure how much further back $ hex constant usage in preprocessor expression has been supported in Apple's USCD Pascal derived compilers. The support was in the first MPW Pascal compiler and may have been supported in the predecessor Lisa Pascal and Apple II compilers but I don't have anything (e.g., documentation) to verify it in the predecessors.)
If for no other reason than to facilitate porting of MacPascal dialect codee to GPC, the preprocessor conditional expression support needs to be fixed to allow usage of $ hex constants.
Compiler used was Adriaan's pre-built GPC Mac OS X version with specs:
Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 Thread model: posix gpc version 20051116, based on gcc-3.4.5
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
While working on a MacPascal dialect to GPC porting project, I was surprised to encounter preprocessor errors in conditional compilation directives where the conditional expression directly or indirectly (i.e., a macro expansion) contained $ hex constants. A short example (thanks Afriaan):
program dollars; {$definec dollars $1} {$ifc dollars = 1} {$endc} begin end.
Compiling yields the error:
dollars.pas:3: conditional expression: parse error
If one changes {$definec dollars $1} to {$definec dollars 1}, it compiles with no problem.
After some futher testing and digging into the gpcpp.c source code, it looks like the preprocessor doesn't support $ hex constants in conditional expressions for conditional compilation directives.
That's right. Neither EP 16#1 constants yet.
When I'll reimplement the preprocessor based on the Pascal lexer as planned, this support will come for free. In the meantime all work on the existing preprocessor will eventually be wasted when it's replaced.
That said, if you (or someone else) would like to add support for `$' for now, feel free to do so. The relevant code is in gpcpp.c: yylex (): "if (*lexptr >= '0' && *lexptr <= '9') ..."
Frank
Frank Heckenbach wrote:
Gale Paeper wrote:
While working on a MacPascal dialect to GPC porting project, I was surprised to encounter preprocessor errors in conditional compilation directives where the conditional expression directly or indirectly (i.e., a macro expansion) contained $ hex constants. A short example (thanks Afriaan):
<snip>
That's right. Neither EP 16#1 constants yet.
When I'll reimplement the preprocessor based on the Pascal lexer as planned, this support will come for free. In the meantime all work on the existing preprocessor will eventually be wasted when it's replaced.
That said, if you (or someone else) would like to add support for `$' for now, feel free to do so. The relevant code is in gpcpp.c: yylex (): "if (*lexptr >= '0' && *lexptr <= '9') ..."
One thing worth doing now it to write test for preprocessor. I have recently checked converage of our testsute and I must say that most of the preprocessor is untested. There may be dead code in preprocessor, but a quick looks gave me an impression that tests just do not use features available in the preprocessor (for example line continuations or non-trivial expressions as conditions).
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Gale Paeper wrote:
While working on a MacPascal dialect to GPC porting project, I was surprised to encounter preprocessor errors in conditional compilation directives where the conditional expression directly or indirectly (i.e., a macro expansion) contained $ hex constants. A short example (thanks Afriaan):
<snip> > > That's right. Neither EP 16#1 constants yet. > > When I'll reimplement the preprocessor based on the Pascal lexer as > planned, this support will come for free. In the meantime all work > on the existing preprocessor will eventually be wasted when it's > replaced. > > That said, if you (or someone else) would like to add support for > `$' for now, feel free to do so. The relevant code is in gpcpp.c: > yylex (): "if (*lexptr >= '0' && *lexptr <= '9') ..."
One thing worth doing now it to write test for preprocessor. I have recently checked converage of our testsute and I must say that most of the preprocessor is untested. There may be dead code in preprocessor, but a quick looks gave me an impression that tests just do not use features available in the preprocessor (for example line continuations or non-trivial expressions as conditions).
Yes, I've never bothered to write extensive tests for most preprocessor features, and apparently nobody else has either.
OTOH, I wonder if we should really test (and thus kind of document) those features that would better (IMHO) be obsoleted. E.g., these ugly backslash-line-continuations are unnecessary with compiler-directive style macros/conditionals (where the comment ending ends the macro/conditional, and there's no problems with backslashes) ...
As was discussed, we may not be able to drop #-directives (though I'd rather like to) for backward-compatibility reasons, but we should consider carefully with other C-inherited features will really be needed (with C syntax) to support "unmodifiable" legacy code. Maybe we won't be able to drop -continuations in the end, but we should at least consider it. And for more obscure C preprocessor features (such as # (stringify) and ## (concat)), I'm even more doubtful we need them (with this strange syntax, as opposed to some magic built-in macros as I previously suggested).
Frank
-
Frank Heckenbach -
Gale Paeper -
Waldek Hebisch