Re: How can I tell if an [out] parameter is NULL?

Ok, the way to solve this is using [local] and [call_as] pair
of methods. For example:

[...]
interface IF
{
[local]
HRESULT GetData([out] BYTE* pData);
[call_as(GetData)]
HRESULT remoteGetData([out] BYTE* pData);
}

The way to marshal these is by writing a pair of routines that are
compiled and linked in the proxy/stub DLL. You can do your
logic there - e.g. fail method invocations with NULL pointer passed.

/* Note this is all C code, not C++! */
/* Put this code in a .C file and add it to the proxy/stub DLL project */
#define COBJINTERFACES
#include "idlheader.h"

HRESULT IF_GetData_Proxy(LPVOID pThis, BYTE* pData)
{
if (data == NULL) {
return E_POINTER;
}
return IF_remoteGetData_Proxy(pThis, pData);
}

HRESULT IF_remoteGetData_Stub(LPVOID pThis, BYTE* pData)
{
return IF_GetData(pThis, pData);
}

Note I've typed this by reading MSDN Library only, so it may not
compile. The documentaion for [call_as] contains several typos which
I did my best to correct, but there may be some left...

As a final note, the remote routine doesn't have to use the same
arguments as the local one. You can add or mutate argument types
as you see fit - your proxy/stub code is responsibe for the proper
argument coercion.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

<philwhite@xxxxxxxxxxxxxx> wrote in message
news:1138181860.850701.270250@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Hi Alexander,
>
> Thanks for replying
> [out, unique] or [out, ptr] won't work, the MIDL compiler chokes on
> them with error MIDL2121.
>
> [in,out] gives me exactly the behaviour i want, but semantically it
> isn't an 'in' pointer
> The documentation states that all [out] parameters must be 'ref' and
> therefore cannot be NULL
> This is true, every time i call the function i get
> RPC_X_NULL_REF_POINTER, it just seems crazy to me that it (marshaling)
> only checks at the end, and that given that this is the case, i cannot
> check within the function
>
> I see loads of 'defensively' programmed examples where they use " if (
> ! param )" but this could never work
> I feel like I'm missing something
>
> Again thanks for replying, and anything else you could suggest would be
> gratefully received
>
> Phil White
>


.

Loading