On 05/11/2012 09:40 PM, Christopher Li wrote:
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?
This seems ok. expanding_macro has to be global not static to be
used... (?)
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.
I think the fact that argument expansion is recursive and
body expansion is non-recursive is one of the things that
make the preprocessor kindof hard to grasp.
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.
I cannot say this before I've tried it.
I'd like to straighten things out a bit: My last emails
where a bit too harsh and I'd like to apologize. Sorry
for that.
The next step then is: I'll write a patch to add a
test-prog that uses this api to trace the token generation
and generate a tree for it.
For a start I'll printout for all tokens of a preprocessor
run all macros-expansions that generated them.
Now, I've learned not to run too fast towards the
goal, (which is still "dependency tee from c parser entities downto
token"), maybe you can think about how to achieve the next steps
in an API :
- An #include #ifdef #else #endif pushdown-stack
to record the nestings for each token
- How to connect all this to the AST.
-- Konrad
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
