This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: Support for %d$c format specifier in diagnostics.c


"Joseph S. Myers" wrote:
> 
> On Mon, 21 Jul 2003, Ishikawa wrote:
> 
> >    (We essentially need the width of the argument to bump the pointer
> > for
> >    variable argument processing  is necessary. So all we need is
> >    the # of bytes for the argument type. The value itself can be opaque,
> >    and will be stored in an appropriate argumet array cell.)
> 
> We need the actual type, not the width.  Passing the wrong type to va_arg
> will lead to 
> (a) aliasing issues (generating wrong code), 
> (b) problems
> with ABIs that handle integer/floating point/pointer arguments differently
> in variable arguments (if such ABIs aren't currently in use, someone will
> one day invent one),
> (c) problems when someone implements a safer ABI that
> stores information about argument types and actually checks at runtime
> that they are correct.  So you should always store information about the
> actual type (distinguishing "int" and "long" even if the same size, for
> example).
[re-indented the quote.]

While I am not conviced of (a), I can see (b) and (c)
will bring up problems in the long term.

> For the format decoders, I'd guess that just the character 'D', 'T', etc.,
> is sufficient to determine what the type is, and so can be stored as an
> opaque identifier itself.  So you need (a) a list of valid characters for
> the front end (needn't be a function, though using a function would keep
> more generality), (b) a function to extract and store the relevant value,
> (c) a function to print the saved value.  Trying to call va_arg to extract
> the value from within diagnostic.c, using some substitute type because
> diagnostic.c shouldn't know about "tree" etc., would I think end up being
> a mistake.

Agreed in principle. 

The problem is that cp/error.c seems to use additional
characters '+' and '#' that  can be used with the expanded set of
format characters (also noted by Gabriel Dos Reis.).
Since diagnostic.c needs to be told
how many characters are eaten up by the decoder to process the format
string
further, I think the use of function rather than the table is in order.

I was afraid that there may be MANY different decoders, but 
by grepping I found only two instances.

    I used find . -name "*.[cChHjJaA]" -print | xargs SEARCHSTRING

    ./gcc/c-objc-common.c:  diagnostic_format_decoder (global_dc) =
&c_tree_printer;
    ./gcc/diagnostic.h:#define diagnostic_format_decoder(DC)
output_format_decoder (&(DC)->buffer)
    ./gcc/cp/error.c:  diagnostic_format_decoder (global_dc) =
cp_printer;

    ./gcc/diagnostic.h:#define output_format_decoder(BUFFER)    
(BUFFER)->format_decoder
    ./gcc/diagnostic.h:/* Same as output_format_decoder.  Works on
'diagnostic_context *'.  */
    ./gcc/diagnostic.h:#define diagnostic_format_decoder(DC)
output_format_decoder (&(DC)->buffer)

c_tree_printer is rather small and easy to handle.
cp_printer (in cp/error.c) is lengthy and complicated, but manageable.

I think I will create the functional interface to request the type
information to
the custom decoder, etc. and modify
cp/error.c and c_tree_printer routine.
I hope these file (cp/error.c) and routine (c_tree_printer)
are not in the state of active modification.
If so, I might want to wait, but given the relatively small size,
I might simply start soon.

Thank you all again for the tips.

Happy Hacking,

Ishikawa, Chiaki





-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */


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