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

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

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).

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.

-- 
Joseph S. Myers
jsm@polyomino.org.uk