Anyone knows this issue? std/math.d(2759): Error: number '0x1p-1024' is not representable

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Sat Jun 20 03:06:12 PDT 2015


On 6/20/2015 2:48 AM, Iain Buclaw via Digitalmars-d wrote:
>
> On 20 Jun 2015 11:35, "Martin Nowak via Digitalmars-d"
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
>  >
>  > On 06/20/2015 09:52 AM, Walter Bright wrote:
>  > >
>  > > Which C runtime are you using? The math functions in C runtimes are
>  > > often inadequate.
>  >
>  > So we now call the host's C library to perform constant folding/CTFE of exp?
>  > This is a point for Iain's proposal to use a high precision floating
>  > point implementation in the compiler to avoid machine/platform differences.
>
> I thought dmd used the C library implementations for all intrinsics via CTFE,
> not just exp?
>
> In any case, isn't the problem you are seeing related to the conversion of
> string to float? Which again dmd is at the mercy of the C library implementation
> to handle correctly.
>

The code is the following, in lexer.c:

   errno = 0;
   (void)Port::strtod((char *)stringbuffer.data, NULL);
   if (errno == ERANGE)
   {
     const char *suffix = (result == TOKfloat32v || result == TOKimaginary32v) ? 
"f" : "";
     error(scanloc, "number '%s%s' is not representable", (char 
*)stringbuffer.data, suffix);
   }

The point of the Port:: code is to correct for inadequacies of various C 
standard library implementations, in this case Debian 7.4.

Apparently we need to roll our own version of strtod() and put it in Port.


More information about the Digitalmars-d mailing list