On Mon, 18 Jun 2007, Al Viro wrote: > > > > That seems like a great approach to me; logically, an initializer should > > expand an array of unspecified size to hold elements up to its maximum index. > > That's what count_array_initializer() is trying to do, but the trouble is > that it doesn't notice that some list elements may end up initializing > parts of the same array member. IOW, it tries to do the right thing, > but to do it correctly you need to look at more than just "this has > explicit designator, this doesn't". > > I'm not sure that I understand the details of type examination in symbol.c > enough to say whether we'd break anything by doing it that way, though. > The question is how much of the laziness would be destroyed by that. > Linus? I really forget - but I do remember that arrays were a bitch from the type handling perspective. We need to examine their types properly early, and then we wanted to set their size as part of that, and there were various subtle ordering requirements there. It is entirely possible that your patch fixes these things, but that whole type evaluation is quite easy to break by mistake.. Linus - 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
