This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c/1027: slightly misleading printf format warning
- To: gdosreis at sophia dot inria dot fr
- Subject: Re: c/1027: slightly misleading printf format warning
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Mon, 11 Dec 2000 12:48:49 -0500 (EST)
- Cc: gcc-bugs at gcc dot gnu dot org, gdr at codesourcery dot com, jsm28 at cam dot ac dot uk
> From: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
>
> | > I've already put in the necessary machinery for so doing in
> | > diagnostics.*. What remains to be done is to replace error_with_decl()
> | > and warning_with_decl() to error() and warning() (maybe error_at())
> | > with use of those specifiers.
> | > -- Gaby
> |
> | If we change error/warning to allow non-standard specifiers then we
> | can't use attribute printf on these functions and we'll lose this
> | valuable error checking in gcc sources, right?
>
> I have trouble to get your point. Could you elaborate?
Here's my point. If I understand your messages correctly, you wish to
change error/warning to accept the %T modifier just like cp_error
(etc), do. In cp-tree.h, it specifically says that cp_error and
friends aren't suitable for attribute printf because it accepts
non-standard specifiers, namely %T.
So if error/warning start to accept %T, then we must remove the
attribute from them and then specifier-vs-arg errors could creep back
in because we no longer check all code paths at compile-time.
Perhaps I've misunderstood what you intend, if so I apologize.
However if I'm correct, then I have concerns over this loss of
compile-time sanity checking.
Many errors were detected when we started putting attribute printf on
our diagnostic functions. I suspect some errors remain in the cp_*
style ones, precisely because they can't do this.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions