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)


On Feb 26 15:15, Howland Craig D (Craig) wrote:
> 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.

Thanks for the offer.  The code might be useful nevertheless, but Chuck
has convinced me that it's not a good idea in the XDR case.


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]