ons, 23.07.2003 kl. 11.41 skrev Mike Hearn:
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).
If it helps, I've been thinking that perhaps the new strict-aliasing stuff in gcc 3.3 has something to do with it. I suppose you could try -fno-strict-aliasing or something; after all, the place where riid is written to is through a typecast, which strict aliasing is hateful of.
Particularly in this case, as REFIID is so very const that you're probably not supposed to assign to a variable of this type at all, and you have to typecast to a non-const pointer type to be able to. With strict aliasing, the compiler will probably ignore the non-const alias and just optimize the initial NULL into any usage of the original const variable.
Of course I could be way off.
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?
Not sure, but more likely because the compiler might actually allocate a stack slot for riid when you leave it uninitialized and then assign to it explicitly in a statement (so that the subsequent typecast will return a pointer to the same memory). With the former initialization, the compiler probably considers the riid having a predefined value (that "won't ever change" because of REFIID's constness), and hence doesn't reserve a stack slot for it; it just uses NULL wherever riid is used (and with strict aliasing, maybe just allocates temporary space for the typecasting, not a real stack slot for riid).
Well, that's my theory anyway. I probably don't have your problem anyway because my own MIDL-generated oaidl_p.c uses an explicit assignment like in your latter case. Alexandre probably just changed it into the former form to avoid some compiler warnings (from assigning to a const variable, probably).