| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
xdr bug?
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 xdr bug? - Nov. 23, '04, 2:30:55 PM
|
|
|
hp
Posts: 25
Joined: Aug. 5, '04,
Status: offline
|
I tried to use xdr to exchange data between Interix, Solaris and Linux. I have no problems to exchange the data between Solaris and Linux, but I can't exchange with Interix.
I get no error, but the result of the decoding is always 0.
I use the following code (removed error handling for readablity):
void encode(double value, char* buf)
{
XDR xdrs;
xdrmem_create(&xdrs, buf, BUFSIZE, XDR_ENCODE);
xdr_double(&xdrs, &value);
xdr_destroy(&xdrs);
}
void decode(double* pvalue, char* buf)
{
XDR xdrs;
xdrmem_create(&xdrs, buf, BUFSIZE, XDR_DECODE);
xdr_double(&xdrs, pvalue);
xdr_destroy(&xdrs);
}
buf is then written to a file or transferred over network (gives the same result).
What is wrong here?
|
|
|
|
 RE: xdr bug? - Nov. 23, '04, 3:06:32 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
This would be odd. The rpc libraries are based on Sun's open version of rpc
and have been used for about 8 years now on Interix.
Is the problem always with xdr_double() ? Or a there other data types too?
What does the "raw" inbound data (I'm assuming this because you wrote decode)
look like on the Interix box just before you call xdr_double?
The only way that xdr_double can return zero is if the long call fails
when the size in the stream is being checked before the double decode starts.
< Message edited by Rodney -- Nov. 23, '04, 3:11:52 PM >
|
|
|
|
|
RE: xdr bug? - Nov. 24, '04, 10:48:04 AM
|
|
|
hp
Posts: 25
Joined: Aug. 5, '04,
Status: offline
|
I have tested the data types bool_t, char, int, float, double, unsigned char, unsigned int, unsigned short and unsigned long now.
bool_t, char, int, float, unsigned char and unsigned int work fine.
unsigned short and unsigned long don't work at all, xdr_u_short() and xdr_u_long() return 0.
xdr_double() returns 1 but creates nonsense.
E.g. the number 98765.0 converted on Interix gives
00 00 00 00 40 f8 1c d0
On all other Unixes it gives
40 f8 1c d0 00 00 00 00
So low and high DWORD are interchanged.
This also explains why all data types that use up to 4 Bytes are converted correctly, and data types that use more than 4 Bytes do not work.
Is this a bug of the xdr library (librpclib.a), or is it some special compiler or linker flag?
And why don't xdr_u_short() and xdr_u_long() work at all?
I don't need them right now, I'm just curious.
< Message edited by hp -- Nov. 24, '04, 10:49:32 AM >
|
|
|
|
|
RE: xdr bug? - Nov. 24, '04, 12:28:11 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
The data (numbers/values) are send in network format using the htonl() and friends
API's and then reverted back using ntonl() and its friends. This is pretty common
behavior for code sending values. How the bytes are arranged on each machine depends
on it's byte order (big endian, little endian, PDP endian, ...).
So to compare between machines in their native byte order you need to known
what the different ones are. Once you convert to network order on each machine
they should all appear the same.
> I don't need them right now, I'm just curious.
They have been working in the past.
I can't take a deeper look until later.
|
|
|
|
|
RE: xdr bug? - Nov. 24, '04, 3:54:07 PM
|
|
|
hp
Posts: 25
Joined: Aug. 5, '04,
Status: offline
|
quote:
So to compare between machines in their native byte order you need to known
what the different ones are.
This is obviously not the problem here, because the byte order is the same but the DWORD order is different.
And, btw., the Linux box and the Interix box have both x86 CPUs.
I still think it is either a bug of the xdr library or the xdr library needs some special treatment that is not documented, e.g. some initialization or something.
I will write a workaround for xdr_double() now, hopefully I don't need any of the other more-than-4-Byte xdr functions.
|
|
|
|
|
RE: xdr bug? - Mar. 7, '05, 1:47:28 AM
|
|
|
preston_tech
Posts: 12
Joined: Feb. 6, '05,
Status: offline
|
We have also run into this problem, where the word order of the two words comprising a double under Interix is the reverse of that under Linux, Solaris, etc. This is not handled in xdr_double() - byte-endianness is but word-endianness isn't. We have created a work-around where we reverse the word order of doubles before reading or writing them via XDR, but would prefer to see a fix for this go into the RPC library in future versions of SFU.
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
