long double in C89?

[Chris Croughton]

Could someone who has access to the C89 specification please confirm
whether the type long double existed in that spec.? The only copy I
have is from the early draft stages, and it wasn't in that (tatty paper
copy). I have tests in some of my source code from the early 90s to
detect whether long double was present (including float.h and testing
for some of the macros), but that may have been for non-conforming
compilers.

(gcc -std=c89 -pedantic accepts it, so it may well be OK, unless gcc has
it as an un-noticed extension...)

Thanks,

Chris C

 

[Eric Sosman]

Could someone who has access to the C89 specification please confirm
whether the type long double existed in that spec.?

Yes, it's there.

 

[lawrence.jones]

Could someone who has access to the C89 specification please confirm
whether the type long double existed in that spec.?

It did.

-Larry Jones

I thought my life would seem more interesting with a musical
score and a laugh track. -- Calvin

 

[Chris Croughton]

Yes, it's there.

Thanks, I can now take out a load of conditional code which was making
things really messy (since I'm not intending that code to target any
compilers before C89). It was getting to be a fire hazard (er,
maintenance hazard)...

Chris C

 

[Keith Thompson]

It did.

One possible source of confusion is that some versions of gcc
incorrectly warn about the "L" length modifier in printf calls:

% cat tmp.c
#include <stdio.h>

int main(void)
{
long double foo = 1.0L;
printf("foo = %Lf\n", foo);
return 0;
}
% gcc --version
2.95.2
% gcc -ansi -pedantic -Wall tmp.c
tmp.c: In function `main':
tmp.c:6: warning: ANSI C does not support the `L' length modifier

In fact, the C90 standard does explicitly support this modifier. This
has been corrected in more recent versions of gcc.

(Strictly speaking, this wasn't a violation of the standard. The
standard allows an implementation to issue any diagnostics it likes,
and doesn't require them to be truthful, and of course there's no
requirement to issue diagnostics for bad format strings. But it was
certainly a bug.)

 

[Chris Croughton]

One possible source of confusion is that some versions of gcc
incorrectly warn about the "L" length modifier in printf calls:

Ah, I think I've seen that. At one time I certainly also had to deal
with some C compilers which didn't have long double or define LDBL_* in
float.h, but those may have been pre-ANSI ones which had adopted some
ANSI features (like prototypes) but not others.

In fact, the C90 standard does explicitly support this modifier. This
has been corrected in more recent versions of gcc.

It seems to have been corrected by 2.95.4 (and is definitely corrected
in the v3 ones).

(Strictly speaking, this wasn't a violation of the standard. The
standard allows an implementation to issue any diagnostics it likes,
and doesn't require them to be truthful, and of course there's no
requirement to issue diagnostics for bad format strings. But it was
certainly a bug.)

It was at least only a warning, even with -pedantic. I do wish they'd
added some other features earlier (like floating point constants in hex
and the A output type).

A problem is that since the C library is divorced from the compiler
itself, the compiler can't warn about things the library accepts or
doesn't implement. For instance, under Cygwin the compiler (gcc 3.3.3)
may be conforming but the library is definitely C99 deficient (only C89
printf formats, no snprintf, no ldexpl but does have ldexpf). As far as
I can see there is no portable way to test a library at compile time for
conforming to any standard (no equivalent of __STDC_VERSION__ for the
library).

Chris C

 

[Keith Thompson]

As far as I can see there is no portable way to test a library at
compile time for conforming to any standard (no equivalent of
__STDC_VERSION__ for the library).

Right, the standard's presumption is that the compiler and the library
are both part of the "implementation". (One way to work around this
is to add a configuration step to your build process that compiles and
executes small test programs to determine what's actually implemented,
then creates a header file that's included by the application.)

 

[Chris Croughton]

Right, the standard's presumption is that the compiler and the library
are both part of the "implementation". (One way to work around this
is to add a configuration step to your build process that compiles and
executes small test programs to determine what's actually implemented,
then creates a header file that's included by the application.)

Oh, I do (I use GNU autoconf which generates a 'configure' script,
running that produces config.h with a load of defines; I also have a
separate program which determines some things which the autoconf script
can't do easily). However, things like whether the format specifiers in
printf conform (and work) are not at all easy to test. Nor are
functions missing (or worse present and non-working) always easy to
detect and duplicate in a portable way (things like ldexpl, for
example). Also the configure script depends on having a unix-like
environment (or at least a Bourne shell equivalent and several standard
utiities like sed), writing it as a C89 program would probably take more
space than the whole of the rest of the library...

Chris C