standard libraries

[Martin Ambuhl]

#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]

Richard Heathfield a écrit :

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]

Mark McIntyre said:

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.

 

[Walter Roberson]

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.

 

[Richard Heathfield]

Walter Roberson said:

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?

 

[Michael Mair]

Walter Roberson said:

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. <[email protected]>.
It was nearly funny to see both of you talk "with" each other ;-/


Cheers
Michael

 

[Richard Heathfield]

Michael Mair said:

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.

 

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

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.h> and <math.h> provide
most of the macros they provide, so that people can write programs that
will work sensibly.

 

[jacob navia]

"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.h> and <math.h> provide
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]

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

 

[jacob navia]

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.

Yeah...

Making long doubles the same as doubles means that there is no
higher precision floating point. Technically you are right,
we can have float == double == long double... but excuse me
there is then only floats and other "types" are just synonyms.

According to the words of the standard the above is legal, but
according to my point of view that is just playing with
words.

 

[Richard Heathfield]

jacob navia said:

Can't you read?

You might want to limit the number of experts you're fighting with at a
time, or your fingers will get awfully tired.

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!!

Oh look. If, for a change, you are correct (and I have no reason to doubt it
here), it appears that some idiot changed the rules by changing a DLL, and
broke working software as a result. That sounds very familiar. DLLs? Just
say no.

 

[CBFalconer]

jacob navia said:
.... snip ...

Oh look. If, for a change, you are correct (and I have no reason
to doubt it here), it appears that some idiot changed the rules by
changing a DLL, and broke working software as a result. That
sounds very familiar. DLLs? Just say no.

No need to go that far. As an implementor, Jacob can easily catch
all printf calls in his own run-time library via a suitable #define
of printf, examine them for long double access, and pass them on
lacking such. Otherwise it may be possible to substitute for the
appropriate routine in the CRTDLL printf interpreter, or to provide
a complete printf replacement. I leave the hairy details to Jacob.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[Keith Thompson]

No need to go that far. As an implementor, Jacob can easily catch
all printf calls in his own run-time library via a suitable #define
of printf, examine them for long double access, and pass them on
lacking such. Otherwise it may be possible to substitute for the
appropriate routine in the CRTDLL printf interpreter, or to provide
a complete printf replacement. I leave the hairy details to Jacob.

The #define trick won't quite do it. This has to work correctly:

#include <stdio.h>
int main(void)
{
#undef printf
long double d = 123.456;
printf("d = %Lg\n", d);
return 0;
}

 

[Ben Pfaff]

As an implementor, Jacob can easily catch all printf calls in
his own run-time library via a suitable #define of printf,
examine them for long double access, and pass them on lacking
such.

I doubt this, because programmers are allowed to #undef standard
library macros to expose the underlying functions. It sounds
like the macro you're suggesting would be needed for correct
operation, not just for an optimization.

 

[jacob navia]

... snip ...



No need to go that far. As an implementor, Jacob can easily catch
all printf calls in his own run-time library via a suitable #define
of printf, examine them for long double access, and pass them on
lacking such. Otherwise it may be possible to substitute for the
appropriate routine in the CRTDLL printf interpreter, or to provide
a complete printf replacement. I leave the hairy details to Jacob.

Yeah, a good printf implementation for C99 is hard.
I know that

I have a good one now. I treat even denormal numbers, printing them
exactly like gcc's printf. I squeeze as much precision in double
and long double precision as possible. Besides, several extensions
that lcc-win32 provides (qfloats for instance) are supported
transparently. You can print qfloats (352 bits floats) just with

printf("%120.100Qf\n",q);

Other "goodies" I am implementing now are the modifications needed
for the safe C library, where
printf_s("%s",strlen(str),str);

The %s directive takes an integer size of the following string.

 

[jacob navia]

The #define trick won't quite do it. This has to work correctly:

#include <stdio.h>
int main(void)
{
#undef printf
long double d = 123.456;
printf("d = %Lg\n", d);
return 0;
}

Yes. At the beginning I had a hack like that, but now I have
py own version of printf, C99 compliant.

 

[CBFalconer]

I doubt this, because programmers are allowed to #undef standard
library macros to expose the underlying functions. It sounds
like the macro you're suggesting would be needed for correct
operation, not just for an optimization.

He only needs to catch the printf calls in some body of code of his
own devising. The #define is obviously a flawed technique. But
whatever he does is system dependent, and he is controlling that
system. A definition of printf in a library loaded before the
system library would suffice. At any rate, the how is a murky
implementation detail.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[Walter Roberson]

Other "goodies" I am implementing now are the modifications needed
for the safe C library, where
printf_s("%s",strlen(str),str);

The %s directive takes an integer size of the following string.

I must be missing the point?

There is already printf("%.*s", (int)strlen(str), str );
where .* causes the precision to be taken from the next argument
(which must be an int). The precision passed is the -maximum- number
of characters to use from the string -- fewer will be used
if the '\0' is hit earlier.

Both printf("%.*s", (int)strlen(str), str ) and
printf_s("%s",strlen(str),str)
at first glance would appear to have the same problem: if you
are relying on strlen() of the passed string to give you
information about the size of the string, then if the string is
not properly terminated, then you are going to pass in the wrong
size and The Fun Begins.

 

[jacob navia]

I must be missing the point?

There is already printf("%.*s", (int)strlen(str), str );
where .* causes the precision to be taken from the next argument
(which must be an int). The precision passed is the -maximum- number
of characters to use from the string -- fewer will be used
if the '\0' is hit earlier.

Both printf("%.*s", (int)strlen(str), str ) and
printf_s("%s",strlen(str),str)
at first glance would appear to have the same problem: if you
are relying on strlen() of the passed string to give you
information about the size of the string, then if the string is
not properly terminated, then you are going to pass in the wrong
size and The Fun Begins.

1) I gave a wrong example (strlen, as you remark, is stupid!)
2) It is not printf but scanf, and I confused those. The scanf
%s argument starts reading and can be dangerous if there is no
length specified

The TR says:

The fscanf_s function is equivalent to fscanf except that the c, s, and
[ conversion
specifiers apply to a pair of arguments (unless assignment suppression
is indicated by a
*). The first of these arguments is the same as for fscanf. That argument is
immediately followed in the argument list by the second argument, which
has type
rsize_t and gives the number of elements in the array pointed to by the
first argument
of the pair. If the first argument points to a scalar object, it is
considered to be an array of
one element.