On Thursday 31 October 2002 09:20 am, Patrik Stridvall wrote:
Greg wrote:
winapi_check tells me:
ndr_stubless.c:86: rpcrt4: LONG_PTR WINAPIV NdrClientCall2(PMIDL_STUB_DESC,PFORMAT_STRING,...): argument 1 documentation: \ /* CLIENT_CALL_RETURN */
This is because winapi_check misparser the line: LONG_PTR /* CLIENT_CALL_RETURN */ RPCRT4_NdrClientCall2(PMIDL_STUB_DESC pStubDesc, PFORMAT_STRING pFormat, va_list args)
Ignore it.
OK. You promise it won't screw up the actual documentation bot?
Promise? Hmm. All code have bugs you know and winapi_check is designed to be ad hoc and thus inherently buggy... :-)
But seriously, I wouldn't worry about it.
Anyway. A real fix to the code you be nice. Presumable the type CLIENT_CALL_RETURN haven't been declared properly.
how shall I deal with these?
Fix them as above or do as everybody elses do wait for me to fix it. :-)
heh. Well, maybe I can set an example for those deadbeats :)
:-)
On Thursday 31 October 2002 12:54 pm, Patrik Stridvall wrote:
Greg wrote:
On Thursday 31 October 2002 09:20 am, Patrik Stridvall wrote:
Ignore it.
OK. You promise it won't screw up the actual documentation bot?
Promise? Hmm. All code have bugs you know and winapi_check is designed to be ad hoc and thus inherently buggy... :-)
But seriously, I wouldn't worry about it.
BUT I CANT SLEEP!!!! (j/k, it's already forgotten)
Anyway. A real fix to the code you be nice.
but I /am/ being nice ;)
Presumable the type CLIENT_CALL_RETURN haven't been declared properly.
no can do, it's that way because of an obscure gcc vs. msvc call convention mismatch for function calls with struct return-types.
anyhow, CLIENT_CALL_RETURN is just a stupid union for casting between longs and ptr's, so, to me, it's just not worth the effort to understand the problem. Basically, I just did what Alexandre told me to, and called it "fixed" :)
A real fix probably involves some crazy wrapper/thunking technique, assembly code, wierd gcc command-line options, an extention to the .spec format, and/or obscure #pragma's -- quite possibly beyond my abilities, and definitely beyond my level of motivation, given the (presumed) non-severity of this particular instance of the problem...
maybe, however, there are some more pressing reasons to solve this, in which case I'd be happy to look at it a bit more carefully (but still skeptical of my ability to solve it).
-
Greg Turner -
Patrik Stridvall