Re: ole32: Void functions should not return a value

[Brian Gerst]

Andrew Talbot wrote:
 Robert Shearman wrote:
 
 Andrew Talbot wrote:
 diff -urN a/dlls/ole32/rpc.c b/dlls/ole32/rpc.c
 --- a/dlls/ole32/rpc.c   2007-03-28 12:43:32.0 +0100
 +++ b/dlls/ole32/rpc.c   2007-04-12 20:20:48.0 +0100
 @@ -1352,7 +1352,7 @@
  TRACE(ipid = %s, iMethod = %d\n, debugstr_guid(ipid),
  msg-ProcNum);
  
  params = HeapAlloc(GetProcessHeap(), 0, sizeof(*params));
 -if (!params) return RpcRaiseException(E_OUTOFMEMORY);
 +if (!params) RpcRaiseException(E_OUTOFMEMORY);
  
  hr = ipid_get_dispatch_params(ipid, apt, params-stub,
  params-chan,
params-iid, params-iface);
 @@ -1360,7 +1360,7 @@
  {
  ERR(no apartment found for ipid %s\n, debugstr_guid(ipid));
  HeapFree(GetProcessHeap(), 0, params);
 -return RpcRaiseException(hr);
 +RpcRaiseException(hr);
  }
  
  params-msg = (RPCOLEMESSAGE *)msg;
   
 You've changed the code paths here.

 
 Hi Rob,
 
 I'm not quite sure what you mean. Are you implying that I need return
 statements after the RpcRaiseException() calls? Can one not just rely on
 the fact that RpcRaiseException() does not return to the caller?
 
 -- Andy.
 
 
 
 

You completely removed the return from the function at those two points,
allowing it to fall through.

--
Brian Gerst

Re: [patch] x86: fix ESP corruption CPU bug

[Brian Gerst]

linux-os wrote:
On Mon, 14 Mar 2005, Jakob Eriksson wrote:
Andi Kleen wrote:
Stas Sergeev [EMAIL PROTECTED] writes:
Another way of saying the same thing: I absolutely hate seeing
patches that fix some theoretical issue that no Linux apps will ever
care about.
No, it is not theoretical, but it is mainly
about a DOS games and an MS linker, as for
me. The things I'd like to get working, but
the ones you may not care too much about:)
The particular game I want to get working,
is Master of Orion 2 for DOS.
How about you just run it in dosbox instead of dosemu ?
Yes, that's a solution of course, but it is a bit like saying why
not use Open Office instead of MS Word.
A long term goal of wine is to support DOS apps to. Of course
it's not a priority, but it's there.
regards,
Jakob
Can you tell me how the invisible high-word (invisible in VM-86, and
in real mode) could possibly harm something running in VM-86 or
read-mode ???  I don't even think it's a BUG. If the transition
into and out of VM-86 doesn't handle the fact that the high-word
of the stack hasn't been used in VM-86, then that piece of code
is bad (the SP isn't even the same stack, BTW).
Because even in 16-bit mode (real, vm86 or 16-bit protected) you can use 
32-bit instructions, with an operand and/or address size override 
prefix.  Of course this only works on 386 or later.

--
Brian Gerst