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.
-- Konrad
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);
you might be right here. expand() is flat when substituting
the body part of the macro. It might work.
-- Konrad
I heard you that this discussion is taking long. That is why I offer
to write up the core sparse part of the change myself and let you
provide feed back to shape it the way we both can happy.
That is the agreement we have earlier right?
So I did exactly what I said I am going to do, now you are calling
me my way vs your way?
My evaluation function is straightly technical merit:
- I prefer patch minimize performance impact on other clients don't
use this feature.
- I prefer simpler interface over complicate one.
To me, believe it or not, It is never about my way vs your way.
If you submit a perfect patch, I would more than happy to apply it.
Apply a patch is much easier than writing one myself.
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
