| Message ID | CANeU7QnfuFjr_bZRqeED8Q54xcm-yeo9-=R8vVHbhvt8ukjxTQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | Mainlined, archived |
| Headers | show |
On Wed, Feb 08, 2017 at 04:32:08AM +0800, Christopher Li wrote: > On Wed, Feb 8, 2017 at 4:12 AM, Luc Van Oostenryck > <luc.vanoostenryck@gmail.com> wrote: > > > > I'm very well aware of this bug/problem, it creates all sort of complications > > but I vaguely understood it was a design choice. To be 100%, you're talking > > the fact that each declaration create a new symbol only related by their > > identifier chain, right? > > Yes. I don't see a way not creating the symbol for each declaration. > However, we can make a better job at migrating the bits between each > declaration. I see roughly a way how we could do that but I'm far from being convinced it would be a good idea. The problem is not that we have one symbol per declaration, it's even not that we have several symbols for the same object, it's that we don't have a central place holding the information about the object. Like, for example, we can't answer something essential like "what is the type of this function" because we have as much types as we have declarations. So yes, verification of the comptability between the declarations and consolidate them is what is missing. Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 8, 2017 at 5:34 AM, Luc Van Oostenryck <luc.vanoostenryck@gmail.com> wrote: > I see roughly a way how we could do that but I'm far from being > convinced it would be a good idea. > The problem is not that we have one symbol per declaration, it's > even not that we have several symbols for the same object, it's > that we don't have a central place holding the information about > the object. Like, for example, we can't answer something essential > like "what is the type of this function" because we have as much > types as we have declarations. As far as I can tell. You can't have one single place to hold type for every declaration. If the declaration is exactly the same, yes. But if the declaration was done in difference scope with different incremental declare, you need to have different version of the same symbol due to the C specification of scoping. See my previous example. The field "same_symbol" is for that purpose tracking the same symbol in different declares. > So yes, verification of the > comptability between the declarations and consolidate them is what > is missing. I think in evaluate.c check_duplicates() does the verification of incompatible declares already. I agree consolidating is missing right now. I am open to suggestions how to fix it. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- sparse.chrisl.orig/parse.c +++ sparse.chrisl/parse.c @@ -2879,8 +2879,10 @@ struct token *external_declaration(struc } } check_declaration(decl); - if (decl->same_symbol) + if (decl->same_symbol) { decl->definition = decl->same_symbol->definition; + decl->op = decl->same_symbol->op; + } if (!match_op(token, ',')) break;