standard libraries

[Richard Heathfield]

Re: standard libraries

jacob navia said:

<snip>

This means that the printf provided by crtdll.dll is strictly
C89 and doesn't provide any way of printing either
long doubles, long longs or any normal printf directives.

That's a contradiction. If it's strictly C89, it will provide a way to print
long doubles.

<snip>

Yes, but microsoft implemented long double as a
synonym for double.

Only in some of their implementations . I have a couple of Microsoft
compilers with 80-bit long doubles, compared to just 64 bits for double.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[jacob navia]

Re: standard libraries

Richard Heathfield a écrit :

jacob navia said:
>
<snip>
>

>>This means that the printf provided by crtdll.dll is strictly
>>C89 and doesn't provide any way of printing either
>>long doubles, long longs or any normal printf directives.

>
>
That's a contradiction. If it's strictly C89, it will provide a way to print
long doubles.
>
<snip>

#include <stdio.h>
int main(int argc, char *argv[])
{
long double d = 1e600L;

printf("%Le\n", d);
return 0;
}

This will FAIL under mingw.

I posted you this message in another thread but you continue
to post nonsense.

>
>

>>Yes, but microsoft implemented long double as a
>>synonym for double.

>
>
Only in some of their implementations . I have a couple of Microsoft
compilers with 80-bit long doubles, compared to just 64 bits for double.
>

Yes, very ancient implementations have real long doubles. Modern ones
have not.

Why confuse people? It is your hobby or what?

[Richard Heathfield]

Re: standard libraries

jacob navia said:

Richard Heathfield a écrit :

>jacob navia said:
>>
><snip>
>>

>>>This means that the printf provided by crtdll.dll is strictly
>>>C89 and doesn't provide any way of printing either
>>>long doubles, long longs or any normal printf directives.

>>
>>
>That's a contradiction. If it's strictly C89, it will provide a way to
>print long doubles.
>>
><snip>

>
>
#include <stdio.h>
int main(int argc, char *argv[])
{
long double d = 1e600L;
>
printf("%Le\n", d);
return 0;
}
>
This will FAIL under mingw.

You claimed:
(a) mingw uses the C runtime library provided in crtdll.dll
(b) the printf provided by that library is strictly C89
(c) the printf provided by that library doesn't provide a way to print long
doubles

It's possible that my C89 draft is wrong, I suppose, but anyway it says:

an optional L specifying that a following e , E , f , g , or G
conversion specifier applies to a long double argument.

Was that removed from the Standard at the last moment?

If so, then all that you have said makes sense. But if not, then I don't
understand what point you are making, as you appear to be contradicting
yourself.

>>>Yes, but microsoft implemented long double as a
>>>synonym for double.

>>
>>
>Only in some of their implementations . I have a couple of Microsoft
>compilers with 80-bit long doubles, compared to just 64 bits for double.
>>

>
Yes, very ancient implementations have real long doubles. Modern ones
have not.
>
Why confuse people? It is your hobby or what?

I am sorry if you find the facts confusing.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[Michael Mair]

Re: standard libraries

jacob navia wrote:

Richard Heathfield a écrit :

>jacob navia said:
><snip>
>>

>>This means that the printf provided by crtdll.dll is strictly
>>C89 and doesn't provide any way of printing either
>>long doubles, long longs or any normal printf directives.

>>
>That's a contradiction. If it's strictly C89, it will provide a way to
>print long doubles.
>>
><snip>

>
#include <stdio.h>
int main(int argc, char *argv[])
{
long double d = 1e600L;
>
printf("%Le\n", d);
return 0;
}
>
This will FAIL under mingw.
>
I posted you this message in another thread but you continue
to post nonsense.

Yes, but the problem is that mingw plus MS libs is _not_ a
conforming implementation.
long doubles, doubles, and floats can have exactly the same size
and representation.
The above code relies on implementation limits rather than
guaranteed standard limits (LDBL_MAX is guaranteed to be at least
1E+37).
The obvious fix is to not use mingw in this combination as it is
broken (or keep in mind that it is broken w.r.t. long double I/O).


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[jacob navia]

Re: standard libraries

Michael Mair wrote:

Yes, but the problem is that mingw plus MS libs is _not_ a
conforming implementation.
long doubles, doubles, and floats can have exactly the same size
and representation.
The above code relies on implementation limits rather than
guaranteed standard limits (LDBL_MAX is guaranteed to be at least
1E+37).
The obvious fix is to not use mingw in this combination as it is
broken (or keep in mind that it is broken w.r.t. long double I/O).
>

This is exactly what I wanted to convey. Same problems appear with
long long.

[Martin Ambuhl]

Re: standard libraries

jacob navia wrote:

>
#include <stdio.h>
int main(int argc, char *argv[])
{
long double d = 1e600L;
>
printf("%Le\n", d);
return 0;
}
>
This will FAIL under mingw.

mingw uses gcc. All recent versions of gcc handle this code just fine,
under either -std=c89 -std=c99 (as well as the -std=gnuxx non-standard
forms of C). If that code "will FAIL" under your copy of mingw, then
you are using a very old version of gcc or you have misinstalled it. I
am assuming that you are making an honest mistake; assuming otherwise
would suggest other possible reasons for your statement.

I posted you this message in another thread but you continue
to post nonsense.

I don't understand why your nonsense, claiming that code that is handled
just fine by gcc is not, should bother him (Richard Heathfield). There
is no reason he should bother with claims that are obviously flawed.

[Mark McIntyre]

Re: standard libraries

On Mon, 02 Oct 2006 11:52:47 +0200, in comp.lang.c , jacob navia
<jacob@jacob.re mcomp.frwrote:

>Richard Heathfield a écrit :

>jacob navia said:
>>
><snip>
>>

>>>This means that the printf provided by crtdll.dll is strictly
>>>C89 and doesn't provide any way of printing either
>>>long doubles, long longs or any normal printf directives.

>>
>That's a contradiction. If it's strictly C89, it will provide a way to print
>long doubles.

>
printf("%Le\n", d);
>
>This will FAIL under mingw.

In which case, as you've alrady been told, it is NOT conformant with
C89, and your point is invalid.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Richard Heathfield]

Re: standard libraries

Mark McIntyre said:

On Mon, 02 Oct 2006 11:52:47 +0200, in comp.lang.c , jacob navia
<jacob@jacob.re mcomp.frwrote:
>

>>Richard Heathfield a écrit :

>>jacob navia said:
>>>
>><snip>
>>>
>>>>This means that the printf provided by crtdll.dll is strictly
>>>>C89 and doesn't provide any way of printing either
>>>>long doubles, long longs or any normal printf directives.
>>>
>>That's a contradiction. If it's strictly C89, it will provide a way to
>>print long doubles.

>>
> printf("%Le\n", d);
>>
>>This will FAIL under mingw.

>
In which case, as you've alrady been told, it is NOT conformant with
C89, and your point is invalid.

Depends on whether L as an fprintf modifier for long double was stricken
from C89 between my draft and the final standard, in which case my original
assertion would be incorrect. Certainly my gcc (2.95.3) seems to think that
%Le is illegal. I'd be curious to hear from anyone with an actual C89
final.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[Walter Roberson]

Re: standard libraries

In article <ldadnVyigZ-kErzYRVny2g@bt. com>,
Richard Heathfield <invalid@invali d.invalidwrote:

>Depends on whether L as an fprintf modifier for long double was stricken
>from C89 between my draft and the final standard, in which case my original
>assertion would be incorrect. Certainly my gcc (2.95.3) seems to think that
>%Le is illegal. I'd be curious to hear from anyone with an actual C89
>final.

It's there in ANSI X3.159-1989, section 4.9.6.1 "The fprintf Function".
Line 20 of page 133.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Richard Heathfield]

Re: standard libraries

Walter Roberson said:

In article <ldadnVyigZ-kErzYRVny2g@bt. com>,
Richard Heathfield <invalid@invali d.invalidwrote:
>

>>Depends on whether L as an fprintf modifier for long double was stricken
>>from C89 between my draft and the final standard, in which case my
>>original assertion would be incorrect. Certainly my gcc (2.95.3) seems to
>>think that %Le is illegal. I'd be curious to hear from anyone with an
>>actual C89 final.

>
It's there in ANSI X3.159-1989, section 4.9.6.1 "The fprintf Function".
Line 20 of page 133.

Thank you. In that case, Mr Navia, who claims both that mingw is
C89-conforming in this regard and that it is not conforming in this regard,
is correct in one way, and incorrect in another. But then, that was bound
to be true, wasn't it? :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[Michael Mair]

Re: standard libraries

Richard Heathfield wrote:

Walter Roberson said:

>>Richard Heathfield <invalid@invali d.invalidwrote:
>>

>>>Depends on whether L as an fprintf modifier for long double was stricken
>>>from C89 between my draft and the final standard, in which case my
>>>original assertion would be incorrect. Certainly my gcc (2.95.3) seems to
>>>think that %Le is illegal. I'd be curious to hear from anyone with an
>>>actual C89 final.

>>
>>It's there in ANSI X3.159-1989, section 4.9.6.1 "The fprintf Function".
>>Line 20 of page 133.

>
Thank you. In that case, Mr Navia, who claims both that mingw is
C89-conforming in this regard and that it is not conforming in this regard,
is correct in one way, and incorrect in another. But then, that was bound
to be true, wasn't it? :-)

*g* True.

However, I think this was more of a communication problem;
Jacob probably did not find the right words to convey what he
wanted to say, c.f. <45215e4d$0$509 5$ba4acef3@news .orange.fr>.
It was nearly funny to see both of you talk "with" each other ;-/


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Richard Heathfield]

Re: standard libraries

Michael Mair said:

<snip>

>
However, I think this was more of a communication problem;
Jacob probably did not find the right words to convey what he
wanted to say,

I think that's probably true. It is the only kind explanation I can find for
much of what he says.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[those who know me have no need of my name]

Re: standard libraries

in comp.lang.c i read:

>those who know me have no need of my name wrote:

>the printf provided by crtdll.dll is strictly
>C89 and doesn't provide any way of printing either
>long doubles, long longs or any normal printf directives.
>
>OK?

long double is part of c89, and microsoft's printf handles it just fine.
they don't support long long at all because as you noted the compiler
conforms to c89, rather than c99. i hesitate to ask what (other)
directives you feel ms' printf does not support but which are "normal".

>long double has been part of the language for a long time [c89 3.1.2.5].

>Yes, but microsoft implemented long double as a
>synonym for double.

so? they are allowed to do that. lots of implementations make the same
decision.

>Since gcc has real long doubles
>the library CRTDLL.DLL does NOT follow and you are stuck

"real"!?!?! as someone that produces a c implementation you surprise me.
ms' long double is just as real as gcc's. that they are different is not
significant except to people writing programs based solely on assumptions.
differences between implementations is why <limits.hand <math.hprovid e
most of the macros they provide, so that people can write programs that
will work sensibly.

--
a signature

[jacob navia]

Re: standard libraries

those who know me have no need of my name wrote:

>
"real"!?!?! as someone that produces a c implementation you surprise me.
ms' long double is just as real as gcc's. that they are different is not
significant except to people writing programs based solely on assumptions.
differences between implementations is why <limits.hand <math.hprovid e
most of the macros they provide, so that people can write programs that
will work sensibly.
>

Can't you read?

The problem is that the gcc compiler used by mingw assumes gcc's
long doubles with 80 bits, and CRTDLL.DLL, the run time library
assumes microsoft "long doubles" with 64 bits!!

This can't work and the programs fail.

I am not critizing anything.

OBVIOUSLY Microsoft can decide that long doubles are
equal to doubles. That is OK. What is NOT OK is that
gcc's mingw compiler has not been modified to adapt to its
run time library or that the run time library has not been
ported to their system.

I am just stating the fact,
proved with an actual code snippet, that you will have problems
when you use both long long and long double under the mingw
system.

THAT's ALL.


Its clear now?

[Mark McIntyre]

Re: standard libraries

On Wed, 04 Oct 2006 22:19:49 +0200, in comp.lang.c , jacob navia
<jacob@jacob.re mcomp.frwrote:

>those who know me have no need of my name wrote:

>>
>"real"!?!?! as someone that produces a c implementation you surprise me.
>ms' long double is just as real as gcc's. t

>
>Can't you read?

Can't you read?

the PP was responding to the part you snipped, in which you said that
MS's long doubles were not real long doubles. Since this is false, he
felt you need called on it.

>I am not critizing anything.

Possibly, but you made an untrue statement and its likely you will get
called on that.

>Its clear now?

It was always clear. What you need to work on is writing a
non-pejorative and non-confrontational manner.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan