Re: fun with declarations and definitions

[Christopher Li <sparse@chrisli.org>]

On Mon, Feb 2, 2009 at 8:13 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>> 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.

I see. So the subsequent declaration for the same symbol should inherent
previous declaration attributes, but no the other way around.

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

Right. I think currently sparse treat the subsequent declaration like a new
one. It check the type is compatible with previous declaration. But it does
not merge the previous declaration information.

> doesn't involve any extensions and having it barf on the second memset call
> there is certainly intended behaviour.

That is good to know. I will keep that in mind.

Chris