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