On Mon, Feb 2, 2009 at 8:13 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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 -- 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
