Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

LDBL_MAX -1.#QNAN0e+000 with MinGW?

18 views
Skip to first unread message

gui...@gmail.com

unread,
Nov 30, 2007, 2:19:34 AM11/30/07
to
I have tried to run this with both eclipse(CDT)+MinGW and Cygwin+GCC

#include <stdio.h>
#include <stdlib.h>
#include <float.h>

int main()
{
puts("The range of ");
printf("\tlong double is [%Le, %Le]∪[%Le, %Le]\n", -LDBL_MAX, -
LDBL_MIN, LDBL_MIN, LDBL_MAX);
return EXIT_SUCCESS;
}

but got different results:

* In eclipse(CDT)+MinGW
The range of
long double is [-1.#QNAN0e+000, 3.237810e-319]∪[6.953674e-310,
0.000000e+000]
* In Cygwin+GCC
The range of
long double is [-1.189731e+4932,
-3.362103e-4932]∪[3.362103e-4932, 1.189731e+4932]

This is weird, and I googled it, then just found this
http://www.thescripts.com/forum/thread498535.html

The LDBL_MAX of long double is machine-dependent, but why it like this
in same machine? I guess it’s the problem with MinGW. Anyone hv any
idea?

Martin Ambuhl

unread,
Nov 30, 2007, 3:25:15 AM11/30/07
to
gui...@gmail.com wrote:
[...]

> The LDBL_MAX of long double is machine-dependent, but why it like this
> in same machine? I guess it’s the problem with MinGW. Anyone hv any
> idea?

No LDBL_MAX is implementation-dependent. That "implementation" is your
compiler, which may choose LDBL_MAX to be something completely
counter-intuitive if your intuition is based on the machine data
representation.

Laurel

unread,
Nov 30, 2007, 3:43:32 AM11/30/07
to
On Nov 30, 6:25 pm, Martin Ambuhl <mamb...@earthlink.net> wrote:

ok, got ur idea. thx :-)

Tim Prince

unread,
Nov 30, 2007, 9:10:17 AM11/30/07
to
gui...@gmail.com wrote:
> I have tried to run this with both eclipse(CDT)+MinGW and Cygwin+GCC
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <float.h>
>
> int main()
> {
> puts("The range of ");
> printf("\tlong double is [%Le, %Le]?[%Le, %Le]\n", -LDBL_MAX, -

> LDBL_MIN, LDBL_MIN, LDBL_MAX);
> return EXIT_SUCCESS;
> }
>
> but got different results:
>
> * In eclipse(CDT)+MinGW
> The range of
> long double is [-1.#QNAN0e+000, 3.237810e-319]?[6.953674e-310,

> 0.000000e+000]
> * In Cygwin+GCC
> The range of
> long double is [-1.189731e+4932,
> -3.362103e-4932]?[3.362103e-4932, 1.189731e+4932]

>
> This is weird, and I googled it, then just found this
> http://www.thescripts.com/forum/thread498535.html
>
> The LDBL_MAX of long double is machine-dependent, but why it like this
> in same machine? I guess it’s the problem with MinGW. Anyone hv any
> idea?
If you run this on a compiler which doesn't support long double in
printf(), results such as these are to be expected.

Keith Thompson

unread,
Nov 30, 2007, 10:44:50 PM11/30/07
to
Tim Prince <timoth...@sbcglobal.net> writes:
[...]

> If you run this on a compiler which doesn't support long double in
> printf(), results such as these are to be expected.

What compilers don't support long double in printf()? The long double
type has been standard since C89.

(Actually, printf is part of the library, not part of the compiler;
both are part of the implementation.)

--
Keith Thompson (The_Other_Keith) <ks...@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Jack Klein

unread,
Nov 30, 2007, 11:47:50 PM11/30/07
to
On Thu, 29 Nov 2007 23:19:34 -0800 (PST), gui...@gmail.com wrote in
comp.lang.c:

> I have tried to run this with both eclipse(CDT)+MinGW and Cygwin+GCC
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <float.h>
>
> int main()
> {
> puts("The range of ");

> printf("\tlong double is [%Le, %Le]?[%Le, %Le]\n", -LDBL_MAX, -


> LDBL_MIN, LDBL_MIN, LDBL_MAX);
> return EXIT_SUCCESS;
> }
>
> but got different results:
>
> * In eclipse(CDT)+MinGW
> The range of

> long double is [-1.#QNAN0e+000, 3.237810e-319]?[6.953674e-310,


> 0.000000e+000]
> * In Cygwin+GCC
> The range of
> long double is [-1.189731e+4932,

> -3.362103e-4932]?[3.362103e-4932, 1.189731e+4932]


>
> This is weird, and I googled it, then just found this
> http://www.thescripts.com/forum/thread498535.html
>
> The LDBL_MAX of long double is machine-dependent, but why it like this

> in same machine? I guess it?s the problem with MinGW. Anyone hv any
> idea?

There is absolutely nothing at all wrong with MinGW, honest. There
might be something wrong with their documentation, if they don't
explain this, or with your situation if they do document this behavior
but you didn't read the documentation.

Probably the most significant difference between the MinGW and Cygwin
packages of gcc, regardless of what IDE or other process you use to
drive them, is not in the compiler. If you get both packages based on
the same gcc version, the compilers are probably identical, or very
close to it.

Your real problem is that MinGW is like a typical gcc distribution,
basically supplied without libraries and links with the host system's
C library.

gcc happens support the full extended precision 80-bit format of the
Intel math coprocessor/FPU for long double. But Microsoft made a
marketing decision a long, long time ago, and decided not to.

Specifically:

"With the 16-bit Microsoft C/C++ compilers, long doubles are stored as
80- bit (10-byte) data types. Under Windows NT, in order to be
compatible with other non-Intel floating point implementations, the
80-bit long double format is aliased to the 64-bit (8-byte) double
format."

You can read the entire sad article on Microsoft's site, in their own
words here:

http://support.microsoft.com/kb/129209

The wording is gibberish, by the way, the 8-bit format is not
"aliased", whatever that means, to 64-bits. It merely means when you
define an object of long double, they use the same 64-bit format that
they use for ordinary double.

So when you use gcc, which does not limit the performance of the Intel
FPU to help Windows NT take over the world, it passed long double
objects and constants to functions as an 80-bit Intel FPU format
object. But Microsoft's library implementation of printf() expects to
receive a 64-bit Intel format value for either double or long double.

The result is undefined behavior.

Cygwin, on the other hand, comes with its own library that expects the
same format for long double that the compiler uses.

To this day, that decision made many years ago, renders Microsoft's
compilers crippled for some types of scientific and engineering
programming.

I'm not a die hard Microsoft basher, but this was certainly an example
of extreme stupidity on their part. They decided that their goal of
world domination was more important than the need of the programmer to
decide when a program needed the maximum precision that the hardware
could provide.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

jacob navia

unread,
Dec 1, 2007, 4:59:03 AM12/1/07
to
Keith Thompson wrote:
> Tim Prince <timoth...@sbcglobal.net> writes:
> [...]
>> If you run this on a compiler which doesn't support long double in
>> printf(), results such as these are to be expected.
>
> What compilers don't support long double in printf()? The long double
> type has been standard since C89.
>

Microsoft

Microsoft doesn't support long double precision, and within its
compiler system it is equal to double precision.

Mingw people, instead of writing a new library as I did for lcc-win,
took the "cheap" way and use Microsoft run time library for
printf and all other functions.

Since gcc internally uses double precision, (they did not change that
to adapt gcc to the run time library) that means that the
compiler generates a printf call passing a real long double
(80 bits) and not a double precision number. This means that
the printf can't suceed.

This is of course not standard, but nobody will complain about that
since gcc is gcc. Only when lcc-win does something as bad as declaring
atof in math.h (what doesn't produce any run time failures in 99.99%
of the programs or more) then hell is raised.


> (Actually, printf is part of the library, not part of the compiler;
> both are part of the implementation.)
>


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia

unread,
Dec 1, 2007, 5:01:52 AM12/1/07
to
Jack Klein wrote:
>
> I'm not a die hard Microsoft basher, but this was certainly an example
> of extreme stupidity on their part. They decided that their goal of
> world domination was more important than the need of the programmer to
> decide when a program needed the maximum precision that the hardware
> could provide.
>


Microsoft is perfectly right to do that since the C standard EXPLICITELY
allows setting long double to double. The error is with gcc/mingw, not
with Microsoft. Mingw uses the run time of Microsoft without adapting
the compiler to the run time library and this is surely not Microsoft's
fault!

If you compile your program with Microsoft it will work correctly since
the compiler generates the right call!

santosh

unread,
Dec 1, 2007, 6:25:48 AM12/1/07
to
jacob navia wrote:

> Jack Klein wrote:
>>
>> I'm not a die hard Microsoft basher, but this was certainly an
>> example
>> of extreme stupidity on their part. They decided that their goal of
>> world domination was more important than the need of the programmer
>> to decide when a program needed the maximum precision that the
>> hardware could provide.
>>
>
>
> Microsoft is perfectly right to do that since the C standard
> EXPLICITELY allows setting long double to double. The error is with
> gcc/mingw, not with Microsoft. Mingw uses the run time of Microsoft
> without adapting the compiler to the run time library and this is
> surely not Microsoft's fault!

Note that Jack said that this Microsoft decision was stupid, not
erroneous.

Richard Heathfield

unread,
Dec 1, 2007, 7:01:16 AM12/1/07
to
jacob navia said:

<snip>

> Microsoft doesn't support long double precision, and within its
> compiler system it is equal to double precision.

Microsoft's implementation supports the long double type, to the precision
required by the Standard to which it conforms.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

jacob navia

unread,
Dec 1, 2007, 6:07:51 AM12/1/07
to
Richard Heathfield wrote:
> jacob navia said:
>
> <snip>
>
>> Microsoft doesn't support long double precision, and within its
>> compiler system it is equal to double precision.
>
> Microsoft's implementation supports the long double type, to the precision
> required by the Standard to which it conforms.
>
> <snip>
>


Yeah

I support bignums provided they do not exceed INT_MAX.

Word games, Word games, and more word games.

Flash Gordon

unread,
Dec 1, 2007, 7:50:46 AM12/1/07
to
jacob navia wrote, On 01/12/07 09:59:

> Keith Thompson wrote:
>> Tim Prince <timoth...@sbcglobal.net> writes:
>> [...]
>>> If you run this on a compiler which doesn't support long double in
>>> printf(), results such as these are to be expected.
>>
>> What compilers don't support long double in printf()? The long double
>> type has been standard since C89.
>
> Microsoft
>
> Microsoft doesn't support long double precision, and within its
> compiler system it is equal to double precision.

Microsoft *does* support the long double type, they just, as you say,
make it the same as double. The standard allows this.

> Mingw people, instead of writing a new library as I did for lcc-win,
> took the "cheap" way and use Microsoft run time library for
> printf and all other functions.
>
> Since gcc internally uses double precision, (they did not change that
> to adapt gcc to the run time library) that means that the
> compiler generates a printf call passing a real long double
> (80 bits) and not a double precision number. This means that
> the printf can't suceed.

MinGW is broken in this regard and does not conform to the C standard.

> This is of course not standard, but nobody will complain about that
> since gcc is gcc.

That is because it is not gcc that is the problem, it is MinGW which
takes gcc and uses it in an incorrect manner (i.e. does not ensure that
both gcc end the library use the same format for long double).

> Only when lcc-win does something as bad as declaring
> atof in math.h (what doesn't produce any run time failures in 99.99%
> of the programs or more) then hell is raised.

The difference is that we don't get people defending MinGW where there
is clear evidence of non-conformance, we do get you defending lcc-win
where there is clear evidence of non-conformance.
--
Flash Gordon

Flash Gordon

unread,
Dec 1, 2007, 9:12:35 AM12/1/07
to
jacob navia wrote, On 01/12/07 11:07:

> Richard Heathfield wrote:
>> jacob navia said:
>>
>> <snip>
>>
>>> Microsoft doesn't support long double precision, and within its
>>> compiler system it is equal to double precision.
>>
>> Microsoft's implementation supports the long double type, to the
>> precision required by the Standard to which it conforms.
>>
>> <snip>
>
> Yeah
>
> I support bignums provided they do not exceed INT_MAX.

Do you claim that a compiler that has a 16 bit int does not have an int?

> Word games, Word games, and more word games.

No, it is true. Had you stated that Microsoft does not support 80 bit
floating point numbers, or that long double was not 80 bit, or something
similar that would have been another matter. However, in this respect
Microsoft does conform to the C standard.

Before too long I should have the latest MS C compiler so I will be able
to see how that conforms to the C standard.
--
Flash Gordon

Keith Thompson

unread,
Dec 1, 2007, 4:05:40 PM12/1/07
to
jacob navia <ja...@nospam.com> writes:
>> Tim Prince <timoth...@sbcglobal.net> writes:
>> [...]
>>> If you run this on a compiler which doesn't support long double in
>>> printf(), results such as these are to be expected.
>>
>> What compilers don't support long double in printf()? The long double
>> type has been standard since C89.
>
> Microsoft
>
> Microsoft doesn't support long double precision, and within its
> compiler system it is equal to double precision.

You are mistaken. Your statement above is consistent with a failure
to understand what "long double" means.

The C standard (both C89/C90 and C99) requires a floating-point type
called "long double". The standard does not require "long double" to
have more precision than "double". If Microsoft supports double and
long double with the same precision, then it *does* support "long
double precision", which happens to be the same as "double precision".
(I use these terms in their C sense, not as defined by the IEC 60559
floating-point standard.)

Note that even Annex F doesn't require an implementation that defines
__STDC_IEC_559__ to provide more precision for double than for long
double. Specifically (C99 F.2p1):

The C floating types match the IEC 60559 formats as follows:

-- The float type matches the IEC 60559 single format.

-- The double type matches the IEC 60559 double format.

-- The long double type matches an IEC 60559 extended format,
else a non-IEC 60559 extended format, else the IEC 60559
double format.

It then recommends, but does not require, using an IEC 60559 extended
format for long double. The use of "else" rather than "or" is a bit
odd; I think it's intended to imply an order of preference.

> Mingw people, instead of writing a new library as I did for lcc-win,
> took the "cheap" way and use Microsoft run time library for
> printf and all other functions.
>
> Since gcc internally uses double precision, (they did not change that
> to adapt gcc to the run time library) that means that the
> compiler generates a printf call passing a real long double
> (80 bits) and not a double precision number. This means that
> the printf can't suceed.

I believe that's correct.

> This is of course not standard, but nobody will complain about that
> since gcc is gcc.

Not true; plenty of people have complained about it.

Note that MinGW is an implementation, not just a compiler. It uses
the gcc compiler in combination with the Microsoft runtime library.
Neither the compiler nor the runtime library is buggy by itself;
they're just incompatible with each other. So this isn't a gcc bug,
or a Microsoft bug; it's a MinGW bug.

There are two possible ways to fix this bug. One would be to modify
the gcc compiler so it uses 64-bit long double (in fact, I'd expect
this to be a gcc configuration option). Another would be to modify
the runtime library (perhaps by replacing parts of it with
non-Microsoft code) so it handles the extended long double format used
by gcc. Some people have argued that Microsoft should "fix" its
runtime library, as well as its own compiler (which is not used by
MinGW), to use extended precision for long double. Though Microsoft's
decision to use 64-bit long double is perfectly conforming, the
argument is that using an extended format would be more useful.

> Only when lcc-win does something as bad as declaring
> atof in math.h (what doesn't produce any run time failures in 99.99%
> of the programs or more) then hell is raised.

Why must you drag your own implementation into this discussion? This
is not about you. Stop whining.

Keith Thompson

unread,
Dec 1, 2007, 4:11:29 PM12/1/07
to
jacob navia <ja...@nospam.com> writes:
> Jack Klein wrote:
>> I'm not a die hard Microsoft basher, but this was certainly an example
>> of extreme stupidity on their part. They decided that their goal of
>> world domination was more important than the need of the programmer to
>> decide when a program needed the maximum precision that the hardware
>> could provide.
>
> Microsoft is perfectly right to do that since the C standard EXPLICITELY
> allows setting long double to double.

To be precise, the standard allows using the same representation for
long double and double. They're still distinct types.

> The error is with gcc/mingw, not
> with Microsoft. Mingw uses the run time of Microsoft without adapting
> the compiler to the run time library and this is surely not Microsoft's
> fault!

The error is in the MinGW implementation. It's an integration bug,
not necessarily a compiler bug or a runtime library bug. It could be
fixed either by changing the compiler or by changing the runtime
library. It's gcc's fault to exactly the same extent that it's
Microsoft's fault. The authors of gcc didn't design their compiler to
be used with Microsoft's runtime library; the authors of Microsoft's
runtime library didn't design it to be used with gcc.

[...]

RoS

unread,
Dec 3, 2007, 2:21:42 AM12/3/07
to
In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:

>Jack Klein wrote:
>>
>> I'm not a die hard Microsoft basher, but this was certainly an example
>> of extreme stupidity on their part. They decided that their goal of
>> world domination was more important than the need of the programmer to
>> decide when a program needed the maximum precision that the hardware
>> could provide.
>>
>
>
>Microsoft is perfectly right to do that since the C standard EXPLICITELY
>allows setting long double to double. The error is with gcc/mingw, not
>with Microsoft. Mingw uses the run time of Microsoft without adapting
>the compiler to the run time library and this is surely not Microsoft's
>fault!
>
>If you compile your program with Microsoft it will work correctly since
> the compiler generates the right call!

wrong
there are numbers that are rappresentable with 80bit float
and not rappresentable with 64bit float

if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)

jacob navia

unread,
Dec 3, 2007, 5:06:43 AM12/3/07
to
RoS wrote:
> In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
>
>> Jack Klein wrote:
>>> I'm not a die hard Microsoft basher, but this was certainly an example
>>> of extreme stupidity on their part. They decided that their goal of
>>> world domination was more important than the need of the programmer to
>>> decide when a program needed the maximum precision that the hardware
>>> could provide.
>>>
>>
>> Microsoft is perfectly right to do that since the C standard EXPLICITELY
>> allows setting long double to double. The error is with gcc/mingw, not
>> with Microsoft. Mingw uses the run time of Microsoft without adapting
>> the compiler to the run time library and this is surely not Microsoft's
>> fault!
>>
>> If you compile your program with Microsoft it will work correctly since
>> the compiler generates the right call!
>
> wrong
> there are numbers that are rappresentable with 80bit float
> and not rappresentable with 64bit float
>

Yes, but as I said above, Microsoft never uses 80 bits
Please read the message before sending this "wrong" stuff!

> if i remember well, if a 64bit float try to rappresent a
> 80bit float should generate in that conversion an exception
> in a x86 cpu (but printf can handle this case returning error)

The CPU is in 64 Bit (double precision), not in 80 bits precision
This setting is used by Microsoft.

James Kuyper

unread,
Dec 3, 2007, 7:29:56 AM12/3/07
to
RoS wrote:
> In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
...

>>
>> Microsoft is perfectly right to do that since the C standard EXPLICITELY
>> allows setting long double to double. The error is with gcc/mingw, not
>> with Microsoft. Mingw uses the run time of Microsoft without adapting
>> the compiler to the run time library and this is surely not Microsoft's
>> fault!
>>
>> If you compile your program with Microsoft it will work correctly since
>> the compiler generates the right call!
>
> wrong
> there are numbers that are rappresentable with 80bit float
> and not rappresentable with 64bit float
>
> if i remember well, if a 64bit float try to rappresent a
> 80bit float should generate in that conversion an exception
> in a x86 cpu (but printf can handle this case returning error)

Sure, but what does that have to do with anything, and what is it you're
saying is "wrong"? If Microsoft C doesn't support any 80bit floating
point types, the issues you raise never come up.

jacob navia

unread,
Dec 3, 2007, 6:42:33 AM12/3/07
to

When jacob navia is the sender of some message, it is
IMPERATIVE to reply with

"wrong"

:-)

santosh

unread,
Dec 3, 2007, 8:38:11 AM12/3/07
to
jacob navia wrote:

> RoS wrote:
>> In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:

<snip>

> Yes, but as I said above, Microsoft never uses 80 bits
> Please read the message before sending this "wrong" stuff!
>
>> if i remember well, if a 64bit float try to rappresent a
>> 80bit float should generate in that conversion an exception
>> in a x86 cpu (but printf can handle this case returning error)
>
> The CPU is in 64 Bit (double precision), not in 80 bits precision
> This setting is used by Microsoft.

Actually the x87 FPU internally supports only the "double extended"
precision 80 bit floating-point type.

jacob navia

unread,
Dec 3, 2007, 8:54:05 AM12/3/07
to

The precision depends on the configuration bit however: you can use
the FPU in full precision (80 bits) or in double precision (64 bits)
This will determined by a bit in the control word of the FPU.
lcc-win sets this bit to full precision (80 bits), and all
calculations will be done using the full precision of the
processor. Microsoft sets it to zero, and all calculations
are done only in double precision.

santosh

unread,
Dec 3, 2007, 8:59:46 AM12/3/07
to
jacob navia wrote:

Okay, and BTW, does lcc-win make use of the XMM registers to speed up
calculations (under appropriate code gen. switches of course).

jacob navia

unread,
Dec 3, 2007, 9:14:02 AM12/3/07
to

Only in the 64 bits versions

CBFalconer

unread,
Dec 3, 2007, 8:55:14 AM12/3/07
to
RoS wrote:
> jacob navia scrisse:
>
... snip ...

>
>> If you compile your program with Microsoft it will work correctly
>> since the compiler generates the right call!
>
> wrong
> there are numbers that are rappresentable with 80bit float
> and not rappresentable with 64bit float
>
> if i remember well, if a 64bit float try to rappresent a
> 80bit float should generate in that conversion an exception
> in a x86 cpu (but printf can handle this case returning error)

Much as it pains me to defend Microsoft, this is not about '80 bit'
floats (which are not a defined type) but about 'long double',
which is defined. The definition allows Microsofts
implementation. It does not allow the Ming implementation.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

RoS

unread,
Dec 3, 2007, 11:21:58 AM12/3/07
to
In data Mon, 03 Dec 2007 11:06:43 +0100, jacob navia scrisse:

>RoS wrote:
>> In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
>>
>>> Jack Klein wrote:
>>>> I'm not a die hard Microsoft basher, but this was certainly an example
>>>> of extreme stupidity on their part. They decided that their goal of
>>>> world domination was more important than the need of the programmer to
>>>> decide when a program needed the maximum precision that the hardware
>>>> could provide.
>>>>
>>>
>>> Microsoft is perfectly right to do that since the C standard EXPLICITELY
>>> allows setting long double to double. The error is with gcc/mingw, not
>>> with Microsoft. Mingw uses the run time of Microsoft without adapting
>>> the compiler to the run time library and this is surely not Microsoft's
>>> fault!
>>>
>>> If you compile your program with Microsoft it will work correctly since
>>> the compiler generates the right call!
>>
>> wrong
>> there are numbers that are rappresentable with 80bit float
>> and not rappresentable with 64bit float
>>
>
>Yes, but as I said above, Microsoft never uses 80 bits
>Please read the message before sending this "wrong" stuff!

excuse me i have read wrong
but LDBL_MAX etc will be different

James Kuyper

unread,
Dec 4, 2007, 6:19:34 AM12/4/07
to
RoS wrote:
> In data Mon, 03 Dec 2007 11:06:43 +0100, jacob navia scrisse:
>> RoS wrote:
>>> In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
...

>>>> Microsoft is perfectly right to do that since the C standard EXPLICITELY
>>>> allows setting long double to double. The error is with gcc/mingw, not
>>>> with Microsoft. Mingw uses the run time of Microsoft without adapting
>>>> the compiler to the run time library and this is surely not Microsoft's
>>>> fault!
>>>>
>>>> If you compile your program with Microsoft it will work correctly since
>>>> the compiler generates the right call!
>>> wrong
>>> there are numbers that are rappresentable with 80bit float
>>> and not rappresentable with 64bit float
>>>
>> Yes, but as I said above, Microsoft never uses 80 bits
>> Please read the message before sending this "wrong" stuff!
>
> excuse me i have read wrong
> but LDBL_MAX etc will be different

Yes; a system which uses the same representation for double and long
double will have the same values for DBL_MAX and LDBL_MAX; that doesn't
make it in any way non-conforming.

Barry Schwarz

unread,
Dec 5, 2007, 9:25:03 PM12/5/07
to

Since the vast majority of floating point numbers are approximations,
whether an 80 bit approximation can be represented with a 64 bit
approximation depends more on the number of bits in the exponent than
the number of bits in the mantissa.


Remove del for email

David Thompson

unread,
Dec 16, 2007, 8:56:35 PM12/16/07
to
On Fri, 30 Nov 2007 22:47:50 -0600, Jack Klein <jack...@spamcop.net>
wrote:
<snip>

> gcc happens support the full extended precision 80-bit format of the
> Intel math coprocessor/FPU for long double. But Microsoft made a
> marketing decision a long, long time ago, and decided not to.
>
> Specifically:
>
> "With the 16-bit Microsoft C/C++ compilers, long doubles are stored as
> 80- bit (10-byte) data types. Under Windows NT, in order to be
> compatible with other non-Intel floating point implementations, the
> 80-bit long double format is aliased to the 64-bit (8-byte) double
> format."
>
> You can read the entire sad article on Microsoft's site, in their own
> words here:
>
> http://support.microsoft.com/kb/129209
>
> The wording is gibberish, by the way, the 8-bit format is not
> "aliased", whatever that means, to 64-bits. It merely means when you
> define an object of long double, they use the same 64-bit format that
> they use for ordinary double.
>
I don't think that's gibberish; I think 'aliased' is just a slightly
clumsy way of saying that long double is another 'name' for double (or
more precisely the type named by double), in their implementations.

Which I agree with you and others is legal, but less useful than using
it to provide the available 80-bit type.

<snip rest>
- formerly david.thompson1 || achar(64) || worldnet.att.net

Tim Prince

unread,
Dec 17, 2007, 1:14:03 AM12/17/07
to

We appeared to disagree on what to call the situation where an
implementation supporting 80-bit long double rides on a library which
supports only 53-bit precision mode.

0 new messages