On Mon, Feb 02, 2009 at 07:07:24PM -0800, Christopher Li wrote:
> On Sun, Feb 1, 2009 at 11:30 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> > Anyway, proposed patch for (1) follows:
>
> I read the patch, seems reasonable. It is only solve the inline case though.
> The more generic problem still exist, symbol look up between partial
> prototype declare and the real declare will get symbol with partial
> information.
... and unfortunately, that's what we _have_ to do. Reason: behaviour
of typeof(). Example:
extern int a[];
int a[__builtin_types_compatible_p(typeof(a),int [3]) + 3]; /* 4 */
int b[__builtin_types_compatible_p(typeof(a),int [3]) + 3]; /* 3 */
Similar for
extern int a[]; /* a is int [] */
typedef typeof(a) A; /* A is int [] _AND_ _WILL_ _REMAIN_ _SO_ */
int a[10]; /* a is int [10] now */
A b; /* int [] */
int b[1]; /* no problem */
Similar applies for functions getting pointers to functions, etc. - having
the type refined by subsequent declaration is not retroactive.
Mind you, we are not doing composite types in any useful way and _that_ is
where we ought to change things. Subsequent declarations should pick
the additional type information; we do propagate the inline definition
back to the call sites, provided that we had the function declared inline
before those. However, the type information should _not_ be spread back.
And it's not just due to typeof (I suspect that honest attempt to define
its semantics in presense of back-propagation like that will end up to
be Turing-complete, but even if it is decidable it's prohibitively hard).
Note that we do have similar effects in standard C - e.g.
extern int a[];
void f(void)
{
extern int a[24];
memset(a, 0, sizeof(a)); /* OK */
}
void g(void)
{
memset(a, 0, sizeof(a)); /* error - sizeof(a) is hidden from us here */
}
doesn't involve any extensions and having it barf on the second memset call
there is certainly intended behaviour.
--
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
