reported this enhancement to fdlibm-comments, and got the following
reply:
Date: Thu, 11 May 1995 14:35:25 -0700
From: Kwok.Ng@Eng.Sun.COM (KC Ng)
To: fdlibm-comments@sunpro.Eng.Sun.COM, jtc@cygnus.com
Subject: Re: fdlibm 5.2: why do core functions use sqrt?
> I noticed that core (e_*.c) fdlibm functions like __ieee754_acos()
> ensure that they call sqrt() with arguments in range (x > 0), when
> they could call __ieee754_sqrt() directly.
>
> Since sqrt() does a lot more work (verifies x is in range, etc.) is
> there any reason for this? I'd think that calling __iee754_sqrt()
> would be more appropriate. ....
You are right. __ieee754_sqrt should be in use with e_*.c.
character string. NA1 says that the 99 characters required by the
Standard have representations in the initial state which are one byte
long and do not alter the state.
Thus we can safely break apart the format string with mbtowc() until
we reach a '%' character, and the process format directive characters
one by one.
We really shouldn't be using mbtowc(), rather mbrtowc() (which takes a
mbstate-t argument) but we don't have the NA1 functions implemented
yet. This is safe, because even when we do we're not likely to
support multi-byte character encodings that use shift states.
types. add xdr_{,u_}int{16,32}_t() functions to convert them.
This is necessary, because things like BPF use the RPC headers to look
at the on-the-wire data, so the headers must accurately represent
what's on the wire, too.
gcc generates slightly better code on all of the architectures I checked.
Also changed xdr_wrapstring to return the return value of xdr_string
directly.
they only take two arguments. Presumably this was done to prevent
problems when users passed xdr_string instead of xdr_wrapstring.
Function prototypes are a better way to fix this "problem".
jtc