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: [patch,complex] Replace hard-coded constants


On Nov 26 09:08, Ralf Corsepius wrote:
> Hi,
> 
> The functions in ctan.c, ctanf.c, catan.c and catanf.c apply
> hard-coded constants which are out of range (i.e. they cause
> compilation warnings and likely will cause run-time failures) on
> some (e.g. 16bit) targets and likely are incorrect on all targets.

Indeed, these values are potentially incorrect for some targets.
However, they are used on BSD this way.

> The patch below tries to replace these hard-coded constants with
> [FLT|DBL_MAX] from <float.h>, when these defines are available and
> tries to fall back to the original constants if these are not
> available.
> 
> Ralf
> 
> PS.: IMO, due to the fact <float.h> and [FLT|DBL]_MAX are POSIX and
> thus should be available in any current compiler, it's likely safe
> to completely remove the hard-coded constants and to directly use
> [FLT|DBL]_MAX.

MAXNUM{F} is only used to construct the return value in case of an
error.  SUSv4 does not indicate what values have to be returned when a
math error occurs.  AFAICS, glibc returns NAN values in real and/or
imaginary part of the number, depending on the problem.

So, for a start I agree that we should drop MAXNUM/MAXNUMF in favor of
using DBL_MAX/FLT_MAX.  But wouldn't it make more sense to use nan/nanf,
like glibc?


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]