Patrik Stridvall ps@leissner.se writes:
This will be VERY slow.
I don't think it will be really different than duplicating all the work the preprocessor is doing inside the parser itself. Of course you want to use the Wine preprocessor, not fork+exec gcc for each file.
OK. I was mainly refering to fork+exec gcc.
But yes parsing all the files is of course slower than having all the info in the .spec, there's no way around that.
Of course.
You now know where a __declspec function begins and ends. This reduces the problem to the parsing of a function declaration. The rest is left as an exersize to the reader. :-)
All you really need is the function name, which should be the last token before the opening '('.
Yes, but which opening? There might be several at nesting level 0.
And searching backward to find the matching ( from the last ) might not be always correct either.
You have the case: void __declspec(dllexport) __attribute__((__stdcall__)) Foo(void) __attribute__((noreturn)) { }
Sure you can have an exception if the name seems to be __attribute__ but then where might be other exceptions.
The only problem is if you want to find the number of args for stdcall decoration, but we should be able to do without it.
That is not a problem. If you find the opening ( before the function name, it would be the number of , at nesting level 1 plus one with the special case of void between the parantesis which means 0.
The problem is that this might work or it might not. You
have no real
guarante that it will.
Well the thing is if you find a declspec you output what you think is the function name. If you get it wrong and output 'WINAPI' or 'char*' instead you'll notice it at build time.
Perhaps. You will easily reach 99% correctness. However beyond that it is hard without a real C parser.
It easy to do that for reasonable functions but for ALL function is much harder. For example you have the special case of a function that returns a function pointer. Not even all C compilers gets that one right, so it normally done with a helping typedef...
Patrik Stridvall ps@leissner.se writes:
You have the case: void __declspec(dllexport) __attribute__((__stdcall__)) Foo(void) __attribute__((noreturn)) { }
Sure you can have an exception if the name seems to be __attribute__ but then where might be other exceptions.
Yes, but a few preprocessor defines can get rid of that.
The only problem is if you want to find the number of args for stdcall decoration, but we should be able to do without it.
That is not a problem. If you find the opening ( before the function name, it would be the number of , at nesting level 1 plus one with the special case of void between the parantesis which means 0.
Except for 64-bit data types...
Perhaps. You will easily reach 99% correctness. However beyond that it is hard without a real C parser.
Well it's clear you can't get 100%, the thing is to make sure it fails in a reasonable way, not just silently breaks. I think it is feasible; whether it is worth the effort is an entirely different question...