[patch,complex] Replace hard-coded constants

Ralf Corsepius ralf.corsepius@rtems.org
Sat Nov 27 16:35:00 GMT 2010

On 11/26/2010 11:19 AM, Corinna Vinschen wrote:
> 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
> 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.
Yes, unfortunately they are pretty vague.

> 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.

Fine with me.

>  But wouldn't it make more sense to use nan/nanf,
> like glibc?
I am inclined to agree.


More information about the Newlib mailing list