[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using m4 between the C preprocessor and compiler?
From: |
Eric Blake |
Subject: |
Re: Using m4 between the C preprocessor and compiler? |
Date: |
Sat, 04 Jul 2009 16:37:15 -0600 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Raphaël “Kena” Poss on 7/3/2009 7:37 AM:
> The other way around (using m4 after the C preprocessor) mostly works,
> but then m4 does not recognize the location markers (#line) inserted by
> the preprocessor and therefore most m4 errors are reported at an
> incorrect location, and multi-line expansions cause m4 to use wrong
> relative numbers in new synclines.
Interesting observation.
> On top of this main issue, I would be interested to disable m4 macro
> expansion within C strings and comments; although I already thought
> about (yet another) filter between CPP and m4 to m4-quote all C strings
> and comments.
With C89, you can use changecom(/*,*/) to avoid m4 expansion within all C
comments. But there is no way (at the moment) to recognize multiple
delimiters (such as C99 /*,*/ vs. //,newline; or in your case "," for C
strings).
> Do you have any suggestions on how to solve the #line-problem and more
> elegantly the string/comment problem?
It would be nice if in the future m4 would allow multiple sets of comment
delimiters, but someone would have to contribute that patch. I think you
are correct that for now you are stuck with another filter pass.
> I tried a possible route forward by replacing any occurrence of "#line
> X" in the m4 input by m4_define(`__line__', X), but unfortunately that
> doesn't seem to help. Is there an option to allow __line__ (and
> __file__) to be reset by macros?
Not at the moment, but I've seriously been considering adding it for m4
1.6. And your use case (of passing files through the C preprocessor, and
wanting #line directives to affect m4 __line__ expansion) certainly makes
it seem more reasonable to provide.
Actually, the syntax that I'm thinking of would be:
__line__ - expand to the current notion of line; this always
autoincrements from prior values as each newline is encountered
__line__(value) - set the new internal line counter value
__file__ - expand to the current notion of file name; generally from the
command line or [s]include builtins, but also from...
__file__(value) - change the internal file name
pushdef(`__line__', `value') - override the builtin __line__, such that
you no longer get autoincrementing until you popdef or go back to the
builtin(`__line__').
- --
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpP2ZcACgkQ84KuGfSFAYDJggCghWFt1tXwbH2Moa5QF0M4YDdO
FPsAn0OG6RGYxRhgJ7Iv0BWxmfu9TZ7c
=araA
-----END PGP SIGNATURE-----