Patrik Stridvall ps@leissner.se writes:
Of course having an imperfect parser also means we cannot
use it for
the export info, because unlike relay debugging it needs
to be 100%
correct. So we either need compiler declspec support,
That will leave us dependent on compilers that support it.
Well, the idea would be not to depend on compiler support for the __declspec keyword itself, but more to have some clever macro replacements that output stuff in a special ELF section or something like that. This could then hopefully be made to work on most compilers. But I'm not sure if there's a good way to do that at all.
It might work, but then it might not.
This isn't happend soon either. It might not be THAT difficult, however the code need not just work it needs be well structured and organized as well if any reasonable guarantees of correctness can be made.
I think most of all it needs to be simple. My idea is to run through the preprocessor,
This will be VERY slow.
find the __declspec, and locate the corresponding function name, or die if there's anything it cannot parse. This should be reasonably foolproof.
A naive idea would be search for __declspec while keeping track of the nesting level (that is how many (, [, { that have not been closed). If the nesting level goes from 1 to 0 before finding the __declspec set a mark. When __declspec is found search backward to mark until you find ; at nesting level 0 or the mark then skip forward any white space. This is extremely likely to be the beginning of a function. Then search forward until { or ; is found when nesting level is 0. Then skip any whitespace backwards.
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. :-)
The problem is that this might work or it might not. You have no real guarante that it will.
And IMO it shouldn't be in Perl, it should be part of winebuild.
That will not make things easier.
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. But yes parsing all the files is of course slower than having all the info in the .spec, there's no way around that.
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 '('. 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.
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.
On 11 Sep 2002, Alexandre Julliard wrote: [...]
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 '('. 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.
This reminded me of ??2@YAPAXI@Z. There's of ton like it in msvcrt and msvcrt20. Can these really be handled just by parsing the Wine sources. It seems like we would have to do quite a bit of type analysis though I'm not sure how much: do the fields composing a structure matter?. Probably not if it's a pointer to.
As a side note, for any solution that removes the need for spec files to be useful to Winelib developpers, it absolutely has to support C++ (think MFC).
At least in the Winelib case it is not a strict requirement to match the name mangling of MSVC. It just means you cannot call Winelib C++ libraries from native ones and vice-versa, which you currently cannot anyway.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"
-
Alexandre Julliard -
Francois Gouget -
Patrik Stridvall