[patch] Add -CC option to cpplib to save comments in macros

Jason R Thorpe thorpej@wasabisystems.com
Wed Jan 2 17:17:00 GMT 2002


On Thu, Jan 03, 2002 at 12:41:08AM +0000, Neil Booth wrote:

 > I tried this in the same way for -C in the 3.1 series (I'd like your
 > -CC to be the behaviour of -C - I'm sure we discussed this 8^)), but I
 > had the same issues that your patch does not address either.  I only
 > removed the feature a few months ago.

Yah, I remember.  I looked over that message you sent me again before
I implemented the change, which is specifically why I chose "-CC" as
the option (-CC is also the name for the option that we have historically
used in NetBSD for this feature, chosen specifically to not change the
semantics of -C).  I wanted to keep the semantics of -C the same (since you
had an example of an application that relied on its behavior).

I'm not actually convinced that making -C behave like my -CC is really
the right thing (and I think I mentioned that to you in an email a while
back).  I.e. I can see merit in both modes.

 > I don't know the right month, but the last discussion about this was
 > probably around October.  You might want to search the mailing list
 > archives, and / or check out testsuite/gcc.dg/cpp/cmdline-C{,2}.c.

Okay, I will look at the testsuite again.

 > The issues I have are:
 > 
 > 1) C++ comments are also preserved, which can be an issue:
 > 
 >    #define foo // comment
 >    foo bar
 > 
 > which would comment out bar.  People did hit this and complain; they
 > wanted to be able to re-compile the output (which -C currently
 > supports).  We could scrap C++ comments in macros, or to convert them
 > to C comments.  The latter is best IMO.

Well, the C++ comment issue was the primary reason I didn't chance the
semantics of -C.

 > 2) You do nothing to lose comments in #if statements.
 > 
 >    #define foo 2 /* Some number */
 >    #if foo > 1
 > 
 > confuses the expression evaluator.

Actually, I noticed that after posting my original patch, fixed it,
and just posted an updated patch a few minutes ago.

 > 3) I _think_ there might be something else, but I've forgotten it 8-)
 >    Ah, yes.  I think it messes up macro expansion if you have
 > 
 >    #define foo() some expansion
 >    foo /**/ ()
 > 
 >    [Pause...] Hmm, we don't get this right even now.

Yah, this is really orthogonal to -CC :-)

 > In view of this, and since fixing issue 3 (which is a real pig - trust
 > me) without unduly hurting run-time performance is not at all trivial
 > IIRC, I'd rather leave this to 3.2 since 3.1 is really in a feature
 > freeze anyway.
 > 
 > Sound reasonable?

Yah, works for me ... I'll just maintain this as a local patch for the
time being.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>



More information about the Gcc-patches mailing list