Re: Your changes to diagnostic machinery

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Gabriel Dos Reis <gdr@integrable-solutions.net>
 > 
 > | Given that, which set do
 > | we choose for files linked into more than one language like
 > | c-common.c?
 > 
 > That is why I suggested the valid format specifiers be registred at
 > run-time instead of being hardwired at compile-time.

There's some miscommuncation here.  When you say "run-time" you must
be meaning something different than what I understand it to mean.  The
format checking framework in gcc is fundamentally a static
compile-time check.  There cannot be any "run-time" registration of
valid formats because all format checks are done at compile-time.  If
you're running the code being compiled, by definition you've already
compiled it so any run-time registration of valid formats is moot.
It's simply too late in the process.

So unless runtime means something else, let's please stop using that
term.

Perhaps you mean extensible format checking?  That's where the valid
formats are defined in the code being compiled.  That's still a
compile-time check, but the format itself is flexible.  If you update
the source code, you can at the same time update the set of valid
specifiers.  That's not available in gcc today.

If that's what you meant, note that it has no impact on our discussion
about c-common.c where we still need to *pick* one format not multiple
ones as you seem to suggest.


 > | If you find yourself needing to use a C++ frontend specifier in
 > | c-common.c, then I suspect that code should really live in the cp/
 > | directory.
 > 
 > No you missed the issue.  
 > I'm just going to remove those attributes.

I haven't missed any issue.

We're just talking past each other, so I'm not going to bother
explaining my points to you or arguing it any further.

Removing the #undef as I suggested puts c-common.c in C frontend
specifier mode mode which I believe it what you want.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu