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