This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Another issue with diagnostic format-checker
> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
>
> What however remains unclear to me is the "Objective-C set". I'm not
> an objc expert and I don't know how objc people want to have their
> front end close to C.
If at some point the objc-set becomes different than the C set, we
merely have to add the appropriate magic to create a separate objc
diag style. It should be relatively easy given that I've already
setup all the infrastructure.
> The diagnostic framework does already some check at run-time. If a front
> end does not register a format specifier, it halts compilation if the
> execution path uses it. So we do have some consistency check.
>
> What the format specifiers checker buys us is the ability to tell
> whether a given pair of format specifier and argument are used
> consistently. It does NOT check whether a format specifier is
> *effectively* handled -- that check is done at run-time.
>
> Both are complimentary, and NOT mutually exclusive.
Well, the consistency check at gcc runtime calls abort if it
encounters a non-valid specifier. That is a "bad user experience"
IMHO. Better to catch these and fix them at gcc compile-time with the
static format checker. If the format checker is doing its job, the
runtime check is redundant. I don't mind having two layers of
checking, but the compile-time one is better IMHO because it catches
specifier problems including those far off the beaten path.
> | On the issue of where we set GCC_DIAG_STYLE, I lean towards leaving it
> | as-is. I.e. have a default in toplev.h, but override it in c-tree.h
> | and cp-tree.h, and live with the file ordering issue.
>
> That requires that every body that includes a file needs to scan them
> to see whether it included files in the right order. Too fragile.
It's not fragile at all. It is *impossible* to include the files in
the wrong order. You'll get macro redefinition warnings if you do.
In c-tree.h/cp-tree.h we define GCC_DIAG_STYLE unconditionally, and in
toplev.h we only define it if not already defined. The tree files
must come first, and gcc will spank you if you get it wrong.
What you can do wrong is omit the c-tree.h or cp-tree.h. In that case
you'll simply be restricted to the generic set until you include one
of the tree files or define GCC_DIAG_STYLE explicitly.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu