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
-
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
