Free Downloads, Community Forum,
FAQs and Developer Resources


Make /Tools Your Home | Link to us

Today's posts | Posts since last visit | Most Active Topics

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
  Printable Version
All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum >> xdr bug? Page: [1]
Login
Message << Older Topic   Newer Topic >>
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?
Post #: 1
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 >

(in reply to hp)
Post #: 2
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 >

(in reply to Rodney)
Post #: 3
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.

(in reply to hp)
Post #: 4
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.

(in reply to Rodney)
Post #: 5
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.

(in reply to hp)
Post #: 6
Page:   [1]
All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum >> xdr bug? Page: [1]
Jump to:





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


Search All Forums -

Advanced search


SPONSORS



Forum Software © ASPPlayground.NET Advanced Edition 2.5 ANSI

0.031