Re: c/1027: slightly misleading printf format warning

[Gabriel Dos_Reis <gdosreis at sophia dot inria dot fr>]

The following reply was made to PR c/1027; it has been noted by GNATS.

From: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: Gabriel Dos Reis <gdr@codesourcery.com>, <cwitty@newtonlabs.com>,
   <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>
Subject: Re: c/1027: slightly misleading printf format warning
Date: Sun, 10 Dec 2000 13:45:40 +0100 (MET)

 | On 10 Dec 2000, Gabriel Dos Reis wrote:
 | 
 | > 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.  That was planed but I didn't get the
 | > chance to finish the work.  Already on my TODO list but I would love
 | > to assist any taker.
 | 
 | What's also needed for the present PR is for the code in cp/error.c for
 | formatting types to move to common code where C can use it as well.  (I'd
 | guess that most of it can probably be shared, though stylistic differences
 | such as "int*" for C++ versus "int *" for C should be allowed for.  
 
 Certainly.  In C++ we tend to systematically print scopes and such.
 But it is true that all those differences can be parameterized through
 call-backs.  The codes in cp/error.c are still under development
 (although there has been no visible activity about them).
 In the long run cp_error() and cp_warning() are supposed to killed in
 favor of error() and warning().
 
 | ... Or, a
 | version covering only C types might be a lot simpler.)  The existing code
 | in c-lang.c
 | 
 |     case 'D':
 |     case 'F':
 |     case 'T':
 |       {
 |         const char *n = DECL_NAME (t)
 |           ? (*decl_printable_name) (t, 2)
 |           : "({anonymous})";
 |         output_add_string (buffer, n);
 |       }
 |       return 1;
 | 
 | along with the default decl_printable_name / decl_name doesn't seem
 | adequate for even the simple case of this PR (where a name for a pointer
 | type should be constructed).
 
 Do you see a better short term solution?
 
 -- Gaby
 CodeSourcery, LLC		http://www.codesourcery.com