On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote: 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? -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993