On Tue, 2003-07-22 at 17:35, Gregory M. Turner wrote:
I was kind of ignoring this as my brain is full with cabinet things ATM... but it sure sounds awfully wrong, doesn't it?
Yeah. I have the feeling that some obscure rule of C is biting me on the backside (again).
./include/rpc.h-54-/* ignore exception handling for now */ ./include/rpc.h-55-#define RpcTryExcept if (1) { ./include/rpc.h-56-#define RpcExcept(expr) } else { ./include/rpc.h-57-#define RpcEndExcept } ./include/rpc.h:58:#define RpcTryFinally ./include/rpc.h-59-#define RpcFinally ./include/rpc.h-60-#define RpcEndFinally ./include/rpc.h-61-#define RpcExceptionCode() 0
Considering the implementation, this seems like an awfully bizarre behavior.
Oops :) I saw all the fascinating code you were throwing around earlier for SEH and assumed that the existing code looked a bit like it. Clearly not.
Perhaps, this really indicates some kind of problem with the loading / linking or the spec.c file or something like that? Does the behavior change if you take out the RpcTryFinally? I would guess not.
It does not. To recap:
REFIID riid = NULL; - fails, because assignments to it are silently ignored
REFIID riid; riid = NULL; - works, because ..... it confuses the gremlins?