This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Comments with -fpreprocessed


Nathan Sidwell wrote:-

> I disagree. 2.95.2 does not accept comments in preprocessed source,
> so accepting them now is a regression.

You call it a regression, I'd call it an enhancement or bugfix,
depending upon my mood :-)

> IMO, options should do exactly what they
> say. `preprocessed' means that comments aren't there. Maybe we should
> allow -C to indicate that they are. I.e.
> 	gcc -E -C foo.c > foo.i			;# generate with comments
> 	gcc -c -C foo.i 			;# accept with comments
> should do what you want. Does that make sense?

Not really.  I don't like that - it would involve a variety of
kludges.

> Do you know of a good reason for wanting to stick -C preprocessed source
> through cc1{,plus}?

Well, we ask people to submit GNATS reports as preprocessed source.
They might want to leave explanatory comments in the code much like
they do in the "how to repeat" or "fix" fields.  In fact, they do this
at the moment - but that's when the code hasn't been through the
preprocessor.  If they give us -C preprocessed code, we can't do
anything with it - gcc won't accept it with or without -fpreprocessed.

I think it's odd to have the ability to reread preprocessed source,
but to refuse to do so if it happended to have been preprocessed with
-C.

> Now, this may all seem like quibling over details, but I find that
> if I'm having to grovel over the preprocessed source in order to
> understand some strange diagnostic, then I'd really like cc1 to
> behave *exactly* the same when given the original source or the
> preprocessed source and appropriate switches.

I think this is bogus - I don't think you can give an example where it
doesn't behave exactly the same, now we've fixed the directive
processing bug, regardless of whether your 2 line patch we're now
discussing is applied or not.

You're fixing a case where the user has edited the preprocessed
output, but that's a situation which is obviously never going to work
all the time, so why fix it in one special case?

But you are now rejecting preprocessed code that would have gone
through cc1 when not preprocessed - something you seem to state above
to be undesirable.

I don't have a strong opinion on this, but I think it is illogical.
I'm happy to wait and see if users bring it up.  If they do, I think
we should revert the patch.

Thanks,

Neil.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]