On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote:
Hi,
Just a bad macro.
ciao, marcus
Changelog: Fixed LITTLE_ENDIAN_32_READ macro to at least compile.
Index: ndr_marshall.c
RCS file: /home/wine/wine/dlls/rpcrt4/ndr_marshall.c,v retrieving revision 1.9 diff -u -r1.9 ndr_marshall.c --- ndr_marshall.c 29 Oct 2002 23:07:33 -0000 1.9 +++ ndr_marshall.c 30 Oct 2002 13:21:15 -0000 @@ -59,8 +59,8 @@
#define LITTLE_ENDIAN_32_READ(pchar) \ (MAKELONG( \
MAKEWORD(*(pchar), *((pchar)+1)) \MAKEWORD(*((pchar)+2), *((pchar)+3)))
MAKEWORD(*(pchar), *((pchar)+1)), \MAKEWORD(*((pchar)+2), *((pchar)+3))))#endif
/*
oops! thanks! strange that this compiles for i386 at all. maybe gcc is automagically fixing the macro for some of us?
On Wed, Oct 30, 2002 at 07:56:10AM -0600, Greg Turner wrote:
On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote:
Hi,
Just a bad macro.
ciao, marcus
Changelog: Fixed LITTLE_ENDIAN_32_READ macro to at least compile.
Index: ndr_marshall.c
RCS file: /home/wine/wine/dlls/rpcrt4/ndr_marshall.c,v retrieving revision 1.9 diff -u -r1.9 ndr_marshall.c --- ndr_marshall.c 29 Oct 2002 23:07:33 -0000 1.9 +++ ndr_marshall.c 30 Oct 2002 13:21:15 -0000 @@ -59,8 +59,8 @@
#define LITTLE_ENDIAN_32_READ(pchar) \ (MAKELONG( \
MAKEWORD(*(pchar), *((pchar)+1)) \MAKEWORD(*((pchar)+2), *((pchar)+3)))
MAKEWORD(*(pchar), *((pchar)+1)), \MAKEWORD(*((pchar)+2), *((pchar)+3))))#endif
/*
oops! thanks! strange that this compiles for i386 at all. maybe gcc is automagically fixing the macro for some of us?
No, if you look at the define, it is not processed on i386 (protected by ifdef).
Ciao, Marcus
On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote:
Fixed LITTLE_ENDIAN_32_READ macro to at least compile.
btw, this seems to imply that even with the parentheses fix, it's still not right... is that the case? You seem like somebody who's up on PPC issues. Note that this is only intended to support UINT32's (I'll make that clearer by changing the macro names in an upcoming patch).
There is another issue with the DataRepresentation stuff that I didn't think of until this morning. NDR allows several different modes in terms of endianness, float representation, signed int representation, etc. MS takes advantage of this by having different "native" data representations, based on the platform. Looking at the Platform SDK rpcndr.h, for example, PPC gets big-endian, i386 gets little-endian.
Then, it seems, they implement their marshall/unmarshall code in terms of these "native" representations. I'm deducing this from the MIDL-generated stub code; that code compares the DataRepresentation coming off the wire to the native DataRepresentation; if there's a mismatch, it converts before calling the unmarshall code (currently the conversion functions are unimplemented in wine).
What this all means, I think, is that my implementation is wrong for non-i386 platforms. I was hard-coding the native data representation to little-endian (the i386 way). This will work for i386, but for other platforms, it will break against precompiled binaries, because the assumed native data representation is compiled right in to the executable via #define's. To fix, I think I need to have per-platform native DataRepresentations like microsoft, and change the marshall/unmarshall code to use it.
Anyhow, just thinking aloud there, and, I guess, hoping that if I'm getting this all wrong, someone will correct me. My original question is the main one: are the semantics of my macro's wrong, or just the parentheses thing?
On Wed, Oct 30, 2002 at 10:13:36AM -0600, Greg Turner wrote:
On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote:
Fixed LITTLE_ENDIAN_32_READ macro to at least compile.
btw, this seems to imply that even with the parentheses fix, it's still not right... is that the case? You seem like somebody who's up on PPC issues. Note that this is only intended to support UINT32's (I'll make that clearer by changing the macro names in an upcoming patch).
The macro appears ok: (*(pchar) = LOBYTE(LOWORD(uint32)), \ *((pchar)+1) = HIBYTE(LOWORD(uint32)), \ *((pchar)+2) = LOBYTE(HIWORD(uint32)), \ *((pchar)+3) = HIBYTE(HIWORD(uint32)), \
It is not byteorder dependend.
...
Anyhow, just thinking aloud there, and, I guess, hoping that if I'm getting this all wrong, someone will correct me. My original question is the main one: are the semantics of my macro's wrong, or just the parentheses thing?
Huh? Just the parentheses thing was wrong I think.
Ciao, Marcus
-
Greg Turner -
Marcus Meissner