On Thu, May 10, 2012 at 5:28 AM, Konrad Eisele <eiselekd@xxxxxxxxx> wrote: > >>> A change like this is bound to need some careful discussion and >>> planing. Yes, I am guilt of only accepting patches meet some subjective >>> stander of mine. But so is to any self respect project maintainers. >>> I would rather spend some time to do it right than commit some thing >>> I would regret later on. >> >> >> Do a B(B(x)) and your sym->parent linked-list will fail. You have a valid point that B(B(x)) will break the sym->parent list. I remove the sym->parent and just use a token_list to maintain the expanding macro. The macro is append to the list when enter and remove from the list when untaint token is reached. The change is in the same review branch. That should solve this problem? > I have to revise my previous assumption though: > > #define B(y) A(x) > B(1) > > i thought that in the body expansion of B recursion is involved, > so that it would yield: > > expand_macro(A); > expand_macro(B); > > but that was wrong, so its > > expand_macro(B); > expand_macro(A); That is right. The macro expansion has 3 stages. The first stage is expand the arguments list while the caller macro does not consider "tainted" during the argument expansion. The macro can recursively appear in the argument list. That is some thing I haven't consider previously. The second stage is just replace the expanded arguments into body. The third stage is rescan the replacement string for macro expand. In this third stage, the macro itself is consider tainted and can't be expand again during the rescan. Can you take a look at this modify version will fit your need or not? I am curious the part weather that will remove the need to add empty token to the list for expansion. In order words, can we design the API clever enough that you don't need to jump through hoops to handle the empty expansion token. Thanks 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
