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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

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

Absolutely right.

| For the format decoders, I'd guess that just the character 'D', 'T', etc.,

In addition of that, some front ends have modifiers like '#' or '+'.

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

the decode calling convention could be modified to take an additional
parameter that tells whether the the actual formatting is desired or
not.  If not desired, it returns true/false depending on whether it
knows how to handle the format specifier.

[...]

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

Right.

-- Gaby