Typelib marshalling BSTRs

Ove Kaaven ovek at arcticnet.no
Thu Jul 24 07:07:33 CDT 2003


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).





More information about the wine-devel mailing list