Re: rpcrt4: Fix a test that fails in win2k3

[Rob Shearman]

2008/7/2 James Hawkins :
> diff --git a/dlls/rpcrt4/tests/ndr_marshall.c b/dlls/rpcrt4/tests/ndr_marshall.c
> index fa19674..abd06dc 100644
> --- a/dlls/rpcrt4/tests/ndr_marshall.c
> +++ b/dlls/rpcrt4/tests/ndr_marshall.c
> @@ -1848,7 +1848,9 @@ static void test_ndr_buffer(void)
>      ok(ret == StubMsg.Buffer, "NdrGetBuffer should have returned the same value as StubMsg.Buffer instead of %p\n", ret);
>      ok(RpcMessage.Handle != NULL, "RpcMessage.Handle should not have been NULL\n");
>      ok(RpcMessage.Buffer != NULL, "RpcMessage.Buffer should not have been NULL\n");
> - ok(RpcMessage.BufferLength == 10, "RpcMessage.BufferLength should have been 10 instead of %d\n", RpcMessage.BufferLength);
> - ok(RpcMessage.BufferLength == 10 ||
> -
>   RpcMessage.BufferLength == 12, /* win2k3 */
> -
>   "RpcMessage.BufferLength should have been 10 or 12 instead of %d\n", RpcMessage.BufferLength);
> ok(RpcMessage.RpcFlags == 0, "RpcMessage.RpcFlags should have been 0x0 instead of 0x%lx\n", RpcMessage.RpcFlags);
>    ok(StubMsg.Buffer != NULL, "Buffer should not have been NULL\n");
>    ok(!StubMsg.BufferStart, "BufferStart should have been NULL instead of %p\n", StubMsg.BufferStart);

I think the behaviour on win2k3 should be marked as broken, since I
can't see any reason why it would need to return more bytes than was
requested.

rpcrt4: Fix a test that fails in win2k3

[Kai Blin]

On Wednesday 02 July 2008 11:52:11 Rob Shearman wrote:
> I think the behaviour on win2k3 should be marked as broken, since I
> can't see any reason why it would need to return more bytes than was
> requested.

Hm, I seem to recall a Samba RPC fix doing the same thing. This seems to be a 
byte alignment thing. If you're interested, I can see if I can dig up the 
appropriate discussion on samba-technical.

Cheers,
Kai

rpcrt4: Fix a test that fails in win2k3

[Rob Shearman]

2008/7/2 Kai Blin :
> On Wednesday 02 July 2008 11:52:11 Rob Shearman wrote:
> > I think the behaviour on win2k3 should be marked as broken, since I
> > can't see any reason why it would need to return more bytes than was
> > requested.
>
> Hm, I seem to recall a Samba RPC fix doing the same thing. This seems to be a
> byte alignment thing. If you're interested, I can see if I can dig up the
> appropriate discussion on samba-technical.

Sure, although I suspect it will be related to packets with
authentication, rather than without which is the case here.

In any case, alignment of the end of the packet should be a task
handled by the RPC layer, not the NDR layer.