Just recently I discovered the usage of the strtold() function in the numeric
literal parsing inside the DMD front end.  strtold() parses a string and returns
a long double representation (80-bit floating point).

I run Linux on a Mini-ITX system from VIA (EPIA Nehemiah M10000 CPU) and my own tests of using strtold() in C programs report incorrect and bizarre results every time.  I guess that's just a limitation of the VIA chipset... However, DMD seems to work fine (read parse numbers correctly) on the same system.  What gives??  Is there some magic going on in DMD for Linux?

Regards,
James Dunne

In article <d89ef6$1df8$1@digitaldaemon.com>, James Dunne says...
>
>Just recently I discovered the usage of the strtold() function in the numeric
>literal parsing inside the DMD front end.  strtold() parses a string and returns
>a long double representation (80-bit floating point).
>
>I run Linux on a Mini-ITX system from VIA (EPIA Nehemiah M10000 CPU) and my own tests of using strtold() in C programs report incorrect and bizarre results every time.  I guess that's just a limitation of the VIA chipset... However, DMD seems to work fine (read parse numbers correctly) on the same system.  What gives??  Is there some magic going on in DMD for Linux?

Probably a stupid question, but are you inspecting the full 80 bits to verify the value?  And I thought the non-Windows compiler was GDC, or are you running this with WINE?


Sean

In article <d89j46$1irb$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <d89ef6$1df8$1@digitaldaemon.com>, James Dunne says...
>>
>>Just recently I discovered the usage of the strtold() function in the numeric
>>literal parsing inside the DMD front end.  strtold() parses a string and returns
>>a long double representation (80-bit floating point).
>>
>>I run Linux on a Mini-ITX system from VIA (EPIA Nehemiah M10000 CPU) and my own tests of using strtold() in C programs report incorrect and bizarre results every time.  I guess that's just a limitation of the VIA chipset... However, DMD seems to work fine (read parse numbers correctly) on the same system.  What gives??  Is there some magic going on in DMD for Linux?
>
>Probably a stupid question, but are you inspecting the full 80 bits to verify the value?  And I thought the non-Windows compiler was GDC, or are you running this with WINE?
>
>
>Sean
>

No, DMD is available for both Win32 and Linux straight from Walter.  It is not GDC.

Personally I haven't tested the 80-bit long double support for the Mini-ITX system, but DMD works fine on it.  I was intrigued to see my own tests for strtold() written in C fail on the system, while similar code in DMD works!

Regards,
James Dunne

Sean Kelly wrote:
> In article <d89ef6$1df8$1@digitaldaemon.com>, James Dunne says...
> 
>>Just recently I discovered the usage of the strtold() function in the numeric
>>literal parsing inside the DMD front end.  strtold() parses a string and returns
>>a long double representation (80-bit floating point).
>>
>>I run Linux on a Mini-ITX system from VIA (EPIA Nehemiah M10000 CPU) and my own
>>tests of using strtold() in C programs report incorrect and bizarre results
>>every time.  I guess that's just a limitation of the VIA chipset... However, DMD
>>seems to work fine (read parse numbers correctly) on the same system.  What
>>gives??  Is there some magic going on in DMD for Linux?
> 
> 
> Probably a stupid question, but are you inspecting the full 80 bits to verify
> the value?  And I thought the non-Windows compiler was GDC, or are you running
> this with WINE?
> 
> 
> Sean
> 
> 

To clear up some confusion you might have, GDC allows D to be run on FreeBSD, MacOS, and any other OS that can use gcc as the compiler. You could run GDC on linux, but since Walter already provides a linux version, I don't think there is much reason to run GDC on linux.

In article <d89tgi$1ta3$1@digitaldaemon.com>, clayasaurus says...
>
>To clear up some confusion you might have, GDC allows D to be run on FreeBSD, MacOS, and any other OS that can use gcc as the compiler. You could run GDC on linux, but since Walter already provides a linux version, I don't think there is much reason to run GDC on linux.

Thanks.  I suppose that explains the *nix binaries that are in the bin directory :p

I don't suppose anyone has tried GDC under WinSFU?  I've been meaning to, but haven't gotten around to it yet.


Sean

clayasaurus wrote:

> To clear up some confusion you might have, GDC allows D to be run on FreeBSD, MacOS, and any other OS that can use gcc as the compiler. You could run GDC on linux, but since Walter already provides a linux version, I don't think there is much reason to run GDC on linux.

Where "linux" for DMD means: a sufficiently new version of Linux X86...
GDC also works on older Linux for X86, as well as Linux PPC (and others)

Another difference is that GDC is Free Software (GPL), where DMD is not.
This is another reason to run GDC on Linux, like for trying patches out?

--anders

IIRC, something is said in the documentation about proper support of 80 bit floating point numbers...

-[Unknown]


> In article <d89j46$1irb$1@digitaldaemon.com>, Sean Kelly says...
> 
>>In article <d89ef6$1df8$1@digitaldaemon.com>, James Dunne says...
>>
>>>Just recently I discovered the usage of the strtold() function in the numeric
>>>literal parsing inside the DMD front end.  strtold() parses a string and returns
>>>a long double representation (80-bit floating point).
>>>
>>>I run Linux on a Mini-ITX system from VIA (EPIA Nehemiah M10000 CPU) and my own
>>>tests of using strtold() in C programs report incorrect and bizarre results
>>>every time.  I guess that's just a limitation of the VIA chipset... However, DMD
>>>seems to work fine (read parse numbers correctly) on the same system.  What
>>>gives??  Is there some magic going on in DMD for Linux?
>>
>>Probably a stupid question, but are you inspecting the full 80 bits to verify
>>the value?  And I thought the non-Windows compiler was GDC, or are you running
>>this with WINE?
>>
>>
>>Sean
>>
> 
> 
> No, DMD is available for both Win32 and Linux straight from Walter.  It is not
> GDC.
> 
> Personally I haven't tested the 80-bit long double support for the Mini-ITX
> system, but DMD works fine on it.  I was intrigued to see my own tests for
> strtold() written in C fail on the system, while similar code in DMD works!
> 
> Regards,
> James Dunne

"James Dunne" <james.jdunne@gmail.com> wrote in message news:d89ef6$1df8$1@digitaldaemon.com...
> Just recently I discovered the usage of the strtold() function in the
numeric
> literal parsing inside the DMD front end.  strtold() parses a string and
returns
> a long double representation (80-bit floating point).
>
> I run Linux on a Mini-ITX system from VIA (EPIA Nehemiah M10000 CPU) and
my own
> tests of using strtold() in C programs report incorrect and bizarre
results
> every time.  I guess that's just a limitation of the VIA chipset...
However, DMD
> seems to work fine (read parse numbers correctly) on the same system.
What
> gives??  Is there some magic going on in DMD for Linux?

The likely source of the difference is that dmd is compiled on my Linux box with whatever strtold is in the C runtime library on *my* box. When you use the dmd binary, you're running the strtold from my box. But when you build an app using strtold, you're using the strtold from *your* box, which might be broken.

BTW, my Linux box is using a VIA chip.