This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Add XDR support (only built #if cygwin, for now)


I don't know of any generic code that does so, but I could easily write
something.  A hard-coded binary32-to-binary64 would be easy.  64 to 32
would require a little bit of thinking about how to handle not fitting.
It's well defined what would happen in a given single executable, but
if XDR is supposed to be able to send the values, do you really want
to get some OK and have some others turned into infinity?  If that
behavior is OK (which is standard for double d = (float) f;), then the
binary64-to-binary32 is also easy.  The bigger question is if you want
people to think that XDR fully works when it is only partial, versus
not allowing double and making it clear that there are trouble spots.
 
The general idea would be (obviously could not be coded this way, since
double is not the right length, but it gets the idea across):

float
b64_to_b32(double d)	// would really be int64_t, not double
{
if(d > FLT_MAX)  {
	errno = ERANGE;
	generate "overflow" floating-point exception
	return(HUGE_VALF);
	}
...
 
Another question would be if it would be worthwhile allowing an
almost-too-small double to turn into a float subnormal or not.
(Complicates the code a bit.)
 
It would be at least a few days for me to get to it and test it
properly.
Let me know if it would be desirable.
 
Craig

-----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
On Behalf Of Corinna Vinschen
Sent: Friday, February 26, 2010 2:50 PM
To: newlib@sourceware.org
Subject: Re: Add XDR support (only built #if cygwin, for now)

On Feb 26 13:52, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > If _DOUBLE_IS_32BITS is set, call xdr_float from xdr_double.
> 
> Hmmm...actually, I think this is wrong.  The XDR stream format of a
> double is supposed to be universal, and is 8 bytes long. If I have an

Good point.  The IEEE float and double formats are well known, though,
so shouldn't it be quite simple to convert a 32 bit IEEE float into 64
bit and vice versa?  Well, that's going a step too far for now, I guess,
but it spoils interoperability a bit.

> I think in this case double support should just be removed.

Yes, I guess so, unless we have generic code to convert 32 bit to 64 bit
FP and vice versa.  Does anybody know?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]