Re: [RFC] show_type() format problems

[Josh Triplett <josht@linux.vnet.ibm.com>]

On Thu, 2007-07-12 at 10:14 +0100, Al Viro wrote:
> int __attribute__((address_space(1))) **p;
> int *__attribute__((address_space(1))) *q;
> 
> void foo(void)
> {
>         p = q;
> }
> 
> quite predictably gives a warning.  The contents of that warning,
> however, is somewhat unfortunate:
> 
> test.c:6:4: warning: incorrect type in assignment (different address spaces)
> test.c:6:4:    expected int **[addressable] [toplevel] p<asn:1>
> test.c:6:4:    got int **[addressable] [toplevel] q<asn:1>
> 
> The reason is simple: we put <asn:...> *after* the identifier.  *, of
> course, goes before it.  So when we have a pointer to pointer, there's
> no way to tell which of them had brought address_space.
> 
> Do we want to keep the current behaviour?  It's obviously not nice -
> especially when we get warnings like one above.
>
> We also can't tell pointer to array from array of pointers.  Does anybody
> object against making it look more like C declarations?  I.e. put <asn:...>
> together with modifiers and at least add parens when needed?

Please do go ahead and change the output.  I'd love for show_type to
output something as close to a parsable C type as possible.

> Believe me, I do realize that it will change build logs.  I probably have
> more of those than just about anybody else (several years worth of sparse
> runs on the kernel for couple dozens of targets).  And yes, it'll hurt.
> I don't see a better alternative, though; we might be able to tweak the
> output to deal with ambiguities and still keep the same results for (very)
> simple cases, but if we are tweaking it at all we really ought to go for
> something recognizable for normal C programmers...

I do understand the concern, but I think that consistency of build logs
matters far less than sanity for the users of *current* Sparse.  Let's
no go making purely gratuitous output changes, but here we have a good
reason to change the output.

- Josh Triplett