standard libraries

[Jim Showalter]

Does a hosted implementation require any particular libraries in order to be
considered a standard C compiler?
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Everything should be made as simple as possible, but not simpler.
_/ -- Albert Einstein
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

[jacob navia]

Jim Showalter wrote:

Does a hosted implementation require any particular libraries in order to be
considered a standard C compiler?

I suppose that the standard C library (at least) should be present.
In any case a compiler without any library is not very useful...

jacob

[Richard Heathfield]

Jim Showalter said:

Does a hosted implementation require any particular libraries in order to
be considered a standard C compiler?

A hosted implementation must provide all the standard library functions, but
the Standard does not say in what form they must be provided.

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

[pete]

Jim Showalter wrote:

>
Does a hosted implementation require
any particular libraries in order to be
considered a standard C compiler?

Yes.

C89, hosted:
<assert.h<locale.h<stddef.h>
<ctype.h<math.h<stdio.h>
<errno.h<setjmp.h<stdlib.h>
<float.h<signal.h<string.h>
<limits.h<stdarg.h<time.h>

C89, freestanding:
<float.h<limits.h<stdarg.h>
<stddef.h>

C99, hosted:
<assert.h<complex.h<ctype.h>
<errno.h<fenv.h<float.h>
<inttypes.h<iso646.h<limits.h>
<locale.h<math.h<setjmp.h>
<signal.h<stdarg.h<stdbool.h>
<stddef.h<stdint.h<stdio.h>
<stdlib.h<string.h<tgmath.h>
<time.h<wchar.h<wctype.h>

C99, freestanding
<float.h<iso646.h<limits.h>
<stdarg.h<stdbool.h<stddef.h>
<stdint.h>

--
pete

[pete]

Richard Heathfield wrote:

>
Jim Showalter said:

Does a hosted implementation require
any particular libraries in order to
be considered a standard C compiler?

A hosted implementation must provide
all the standard library functions, but
the Standard does not say in what form they must be provided.

Yes.

This directive in a C file: #include <float.h>
only means that the compiler has to compile the C file
as though float.h was pasted in there.
If that can be done without a float.h file being present,
then there doesn't need to be a float.h file
in the hosted implementation.

--
pete

[Jim Showalter]

jacob navia wrote:

>
I suppose that the standard C library (at least) should be present.
In any case a compiler without any library is not very useful...

jacob

That's what I thought, too. But I've installed the latest versions of MinGW
along with gcc-core, and cannot find even a mention of libc or glibc.

--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Everything should be made as simple as possible, but not simpler.
_/ -- Albert Einstein
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

[Keith Thompson]

Jim Showalter <ji***********@hotmail.comwrites:

jacob navia wrote:

>I suppose that the standard C library (at least) should be present.
In any case a compiler without any library is not very useful...

That's what I thought, too. But I've installed the latest versions
of MinGW along with gcc-core, and cannot find even a mention of libc
or glibc.

The standard says nothing about "libc" or "glibc". As long as a
program that includes standard headers and calls standard library
functions works as specified in the standard, it doesn't matter how
the implementation does it.

<OT>gcc typically uses whatever runtime library is provided by the
underlying operating system. I don't know what MinGW does.</OT>

If you're curious about the details of how your implementation
provides the standard library headers and fucntions, either check your
implementation's documentation or ask in a system-specific newsgroup.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

pete said:

Jim Showalter wrote:

>>
Does a hosted implementation require
any particular libraries in order to be
considered a standard C compiler?

Yes.

C89, hosted:
<assert.h<locale.h<stddef.h>

[etc]

Those are not libraries. They're headers.

<snip>

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

[Richard Heathfield]

pete said:

Richard Heathfield wrote:

>>
Jim Showalter said:

Does a hosted implementation require
any particular libraries in order to
be considered a standard C compiler?

A hosted implementation must provide
all the standard library functions, but
the Standard does not say in what form they must be provided.

Yes.

This directive in a C file: #include <float.h>
only means that the compiler has to compile the C file
as though float.h was pasted in there.
If that can be done without a float.h file being present,
then there doesn't need to be a float.h file
in the hosted implementation.

What has <float.hto do with libraries?

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

[Malcolm]

"Jim Showalter" <ji***********@hotmail.comwrote

>
Does a hosted implementation require any particular libraries in order to
be
considered a standard C compiler?

Yes. the standard library.
The problem is that most hosted implementations run on computers with
graphical user interfaces, and there are no standard library functions for
communicating with a GUI. Some evil systems also take away streams such as
stderr and stdout, which makes life very difficult.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

[pete]

Richard Heathfield wrote:

>
pete said:

Jim Showalter wrote:

>
Does a hosted implementation require
any particular libraries in order to be
considered a standard C compiler?

Yes.

C89, hosted:
<assert.h<locale.h<stddef.h>

[etc]

Those are not libraries. They're headers.

<snip>

Parts of the standard library,
are sometimes refered to as "libraries",
such as "the math library",
which is mentioned in the FAQ.

http://c-faq.com/fp/libm.html

--
pete

[jacob navia]

Jim Showalter wrote:

jacob navia wrote:

>>I suppose that the standard C library (at least) should be present.
In any case a compiler without any library is not very useful...

jacob

That's what I thought, too. But I've installed the latest versions of MinGW
along with gcc-core, and cannot find even a mention of libc or glibc.

mingw doesn't have an own version of the standard C
Library and uses the implementation provided with the
operating system: crtdll.dll.

This rather ancient implementation will provide you with
C89 semantics with a compiler that can possible emit
C99 code, so take care as not to ask for anything
recent what standards is concerned.

At the same time, even if the compiler accepts and emits
code for long doubles, mingw doesn't have any library support
for long doubles so better not use them.

The same with long longs, since the printf version of crtdll.dll
doesn't understand any long long semantics. Maybe it understands
long long ll;
printf("%I64d\n",ll);

but I am not sure about it.

Another possibility is that you make mingw link with the
C library of the microsoft compiler system, but I do
not know how to do that or if it is fair to do this (use
Microsoft's libraries without buying a copy of the
Microsoft compiler); See your lawyer for additional
information :-)

jacob

[Richard Heathfield]

pete said:

Richard Heathfield wrote:

>>
pete said:

Jim Showalter wrote:

Does a hosted implementation require
any particular libraries in order to be
considered a standard C compiler?

Yes.

C89, hosted:
<assert.h<locale.h<stddef.h>

[etc]

Those are not libraries. They're headers.

<snip>

Parts of the standard library,
are sometimes refered to as "libraries",

Erroneously.

such as "the math library",
which is mentioned in the FAQ.

http://c-faq.com/fp/libm.html

If you read it more carefully, you'll see that the question addresses the
/difference/ between headers and libraries. When it's talking about "the
math library", it is talking about "actually linking with the math
*library*", not "linking with the <math.hheader". You don't link with
headers.

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

in comp.lang.c i read:

[re: platform provided standard c library]

>This rather ancient implementation will provide you with
C89 semantics with a compiler that can possible emit
C99 code, so take care as not to ask for anything
recent what standards is concerned.

eh? decoder ring needed.

>At the same time, even if the compiler accepts and emits
code for long doubles, mingw doesn't have any library support
for long doubles so better not use them.

that would be sad then, since long double has been part of the language for
a long time [c89 3.1.2.5].

--
a signature

[jacob navia]

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

in comp.lang.c i read:

[re: platform provided standard c library]

>>This rather ancient implementation will provide you with
C89 semantics with a compiler that can possible emit
C99 code, so take care as not to ask for anything
recent what standards is concerned.

eh? decoder ring needed.

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.

OK?

>

>>At the same time, even if the compiler accepts and emits
code for long doubles, mingw doesn't have any library support
for long doubles so better not use them.

that would be sad then, since 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. Since gcc has real long doubles
the library CRTDLL.DLL does NOT follow and you are stuck

[Richard Heathfield]

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]

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]

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]

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]

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]

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]

On Mon, 02 Oct 2006 11:52:47 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.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]

Mark McIntyre said:

On Mon, 02 Oct 2006 11:52:47 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.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]

In article <ld********************@bt.com>,
Richard Heathfield <in*****@invalid.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]

Walter Roberson said:

In article <ld********************@bt.com>,
Richard Heathfield <in*****@invalid.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]

Richard Heathfield wrote:

Walter Roberson said:

>>Richard Heathfield <in*****@invalid.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. <45**********************@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]

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]

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

--
a signature

[jacob navia]

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.hprovide
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]

On Wed, 04 Oct 2006 22:19:49 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.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

[jacob navia]

Mark McIntyre wrote:

On Wed, 04 Oct 2006 22:19:49 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.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.

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:

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

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.

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

[CBFalconer]

Richard Heathfield wrote:

jacob navia said:

.... snip ...

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

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:
<news:news.announce.newusers
<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]

CBFalconer <cb********@yahoo.comwrites:
[...]

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;
}

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ben Pfaff]

CBFalconer <cb********@yahoo.comwrites:

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.
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl

"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt

[jacob navia]

CBFalconer wrote:

Richard Heathfield wrote:

>>jacob navia said:

... snip ...

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

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]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:
[...]

>>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;
}

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

[Walter Roberson]

In article <45**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

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

--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[jacob navia]

Walter Roberson wrote:

In article <45**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

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

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.

[CBFalconer]

Ben Pfaff wrote:

CBFalconer <cb********@yahoo.comwrites:

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

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:
<news:news.announce.newusers
<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/>