On September 11, 2002 10:23 am, Patrik Stridvall wrote:
However how do know whether it is IN/OUT or OUT?
Excellent point. There aren't that many IN/OUT cases anyway (can you produce a count?),
Well as I said a lot of API use LPSTR when it really should use LPCSTR so the potential IO/OUT cases are quite a few.
but we would need to add some metainfo at the source level. No big deal, really...
You mean just add a OUT before the type. That is quite easy to parse.
On September 11, 2002 11:07 am, Patrik Stridvall wrote:
Well as I said a lot of API use LPSTR when it really should use LPCSTR so the potential IO/OUT cases are quite a few.
I don't think it's "lot". Can you give a count where LPSTR/LPWSTR is used for a IN parameter only? And those we can fix in our sources, as you said.
You mean just add a OUT before the type. That is quite easy to parse.
Even better -- encode it in the typeinfo.
/* M = modifiable */ typedef LPSTR LPMSTR; typedef LPWSTR LPMWSTR;
Use LPM{,W}STR instead of LP{,W}STR where the parameter is an IO one. The type are equivalent, so no one will notice a difference except our parsing tool.
BTW, how many are IO? I would suspect most are O only...
"Dimitrie O. Paun" dpaun@rogers.com writes:
Even better -- encode it in the typeinfo.
/* M = modifiable */ typedef LPSTR LPMSTR; typedef LPWSTR LPMWSTR;
Use LPM{,W}STR instead of LP{,W}STR where the parameter is an IO one. The type are equivalent, so no one will notice a difference except our parsing tool.
This way lies madness. The parser shouldn't require any modification to the source, and should work on any Windows source, not only the Wine ones. This means there are basically two approaches:
1. write a full C compiler 2. use Patrik's Perl stuff to generate the initial info as best as we can and then update it by hand.
IMO #2 is the way to go, because no matter how clever a parser you write it won't be able to extract semantics information; and that would be the main advantage of doing a better relay debugger. Imagine dumping structure contents, flags, following list pointers, etc. We shouldn't limit ourselves to what can be extracted automatically from the source.
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, or we need a specialized tool to extract the declspec info in a way that is guaranteed to not miss anything.
On September 11, 2002 12:06 pm, Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
Even better -- encode it in the typeinfo.
/* M = modifiable */ typedef LPSTR LPMSTR; typedef LPWSTR LPMWSTR;
This way lies madness. The parser shouldn't require any modification to the source, and should work on any Windows source, not only the Wine ones.
But I'm not suggesting we generalize this approach. We need this only for IN/OUT strings. And there are just a few cases where that's so. If you use LPSTR instead, nothing bad happens, just that during relaying you will not see the value of the string going in.
It's just an idea, I don't think it's as bad as you seem it is, but I'm also not convinced it's worth the trouble. We don't have this feature right now, and it's not a big deal.
But for the sanity of the discussion, I'll drop it right now. :)
We shouldn't limit ourselves to what can be extracted automatically from the source.
But this were I don't agree with you. Experience has shown times and again that having a central place where related things sit is better than duplicating the info all over the place. That's why documentation extacted directly from source has won. No question about it. May not be perfect, but long term is the best solution.
Now, it is true that we may need some metainfo not present in a bare source to do all sorts of nice bells and whistles. But that should be included as empty macros or comments in the code, such that we can extract automatically all that needs extracting.
"Dimitrie O. Paun" dpaun@rogers.com writes:
But this were I don't agree with you. Experience has shown times and again that having a central place where related things sit is better than duplicating the info all over the place. That's why documentation extacted directly from source has won. No question about it. May not be perfect, but long term is the best solution.
Now, it is true that we may need some metainfo not present in a bare source to do all sorts of nice bells and whistles. But that should be included as empty macros or comments in the code, such that we can extract automatically all that needs extracting.
Again this works only if you are limiting yourself to the easy stuff. If you want more than that you have to write actual code, and you don't want to do that in a function header comments. As for grouping related things, it's not clear that grouping all relay code in a single file is worse than spreading it all over the source. Especially once you start adding more intelligence and interdependencies between functions and structures.
And of course you don't always have the source in the first place; a big advantage of keeping it separate would be to do a smart +snoop for binary dlls.
-
Alexandre Julliard -
Dimitrie O. Paun -
Patrik Stridvall