[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: Gecko/20090605 Thunderbird/ Mnenhy/

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

> 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

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]