checking double for Inf or NaN - how?

[Chris Hills]

jacob navia said:


The 1989 Standard is far from obsolete. It is still the current de facto
Standard,

I think you mean ISO 9899:1990 + A1 and the TC's aka C95

C89 is a local US standard that was superseded by the ISO standard in
1990.

and will remain so until C99 is widely implemented. That day
appears to be some way off - the GNU people have shied away from full
conformance to C99, and Microsoft have ignored it completely.

The C Standard is of no value unless it enables us to write portable code.

I don't agree there. There are few truly portable apps. However I agree
that the c standard is of little use unless the language as defined in
the standard is of use and implimentable in the majority of compilers.
Or the majority of it implimentable in All compilers.

C99 features are, quite simply, not even remotely as portable as C89
features.

Neither, it appears, are they wanted by the majority.

 

[Chris Hills]

Richard Heathfield a écrit :

This is your opinion. Your are entitled to it Mr Heathfield, but it is
not mine anyway. There are people that will stay in the past, longing
for the lost "golden times"...

In some cases fools rush in where angles fear to tread.

The problem is AFAICS that C99 contains things that are broken and not a
good idea which is why the compiler vendors did not rush to implement
it. Neither have the majority of users demanded them.

If you look at the recent argument about the "Spawn of Satan M$" who are
working with ECMA on C++/CLI (also C#) for desktop use and then note
that MISRA took C90 as a base for embedded use. Put that against the
fact that several of the ISO C panel have said they regret several
features got into C99 you have to ask what is the point of C99?

It appears that the ISO standards have departed from industry usage and
practice. There are other "standards" being developed by the industry
that are in use or the de-facto standards.

ISO BASIC died whilst VB is widely used.

"Portability" for you means "taking the worst features of each
implementation".

There are C99 compilers under windows, and under Unix.

Very few but we have been here before. :-( Let's not argue that again.

 

[Chris Hills]

jacob navia said:


He also mentioned the Mac.


The general assumption in comp.lang.c is that the code is targeted at a
hosted implementation

Only by some people.

The other thing to consider is that the majority of C implimentations
are more likely to be in the embedded space (there are probably at least
4 compilers for any embedded target and dozens of targets) since AFAIK
most desktop systems have moved to C++, C# and C++/CLI etc

of unknown provenance (unless it is specifically
mentioned that a freestanding implementation is targeted). If the platform
matters, well, there are other newsgroups where such discussions can be
held.

However the language as defined should be implimentable on the majority
of compilers/platforms or the majority of the language on all of the
compilers/platforms.

As I have said before if you only want to discus PURE ISO c (ie C99) on
a hosted target then you are very sorely limited.

 

[Richard Tobin]

Those are the operating systems mentioned in the original poster's
message.

[/QUOTE]

He also mentioned the Mac.

Macs run unix these days.

-- Richard

 

[Chris Hills]

He also mentioned the Mac.

Macs run unix these days.

-- Richard[/QUOTE]

AFAIK
OSX was developed from NEXT Step OS which was developed from BSD Unix.

 

[jacob navia]

Richard Tobin a écrit :

He also mentioned the Mac.

Macs run unix these days.
[/QUOTE]

Yes but he is using a mac vintage 1989...



jacob

 

[pete]

C99 features are, quite simply, not even remotely as portable as C89
features.

I like the added restrictions of C99,
such as no implicit int
and requiring protypes for all functions.

C89 code, written with the additional restrcitions of C99,
is better formatted C89 code.

 

[pete]

jacob navia said:

That's just for code posted to the newsgroup.

The group is about the language,
not "your" implmentation,
("your", for all possible values of "you").

 

[pete]

jacob navia wrote:

"Portability" for you means "taking the worst features of each
implementation".

That is what it means.

The C programming language (the topic of the group),
is defined in terms of the abstract machine.

 

[pete]

That's just for code posted to the newsgroup.

The group is about the language,
not "your" implmentation,
("your", for all possible values of "you").

I don't have a problem with posted code
that is for specific implementation defined situations
such as where CHAR_BIT equals eight and sizeof(int) equals four,
and as long as the implementation defined restrictions
for the code are completely specified, in the post.

I'm only interested in the name of a compiler
when the issue is
whether or not it is a conforming implementation.

 

[Richard Heathfield]

Chris Hills said:

I think you mean ISO 9899:1990 + A1 and the TC's aka C95

Quite so. Shorthand, my dear chap, shorthand. (And, of course, I was echoing
JN's use of "1989".)

I don't agree there. There are few truly portable apps.

I didn't say "apps". I said "code". Personally, I write a lot of portable
programs, but that's neither here nor there. The value of the Standard is
that it allows us to divide our application code into portable and
non-portable parts, so that only the non-portable part need be rewritten
for each port to a new platform. If this is done well, as much as 99% of a
GUI application can be ported without change (I've certainly experienced
this with a half-million-line set-top-box application, which had to be
ported to all manner of platforms, including those with weird CHAR_BITs and
the like).

The Standard helps us to divide the code appropriately. If the Standard is
not /implemented/ (sufficiently widely), though, there isn't much point in
paying attention to it. That is the position C99 is in.

Neither, it appears, are they wanted by the majority.

Right - so I see no reason to bother with C99 at all.

 

[Richard Heathfield]

Richard Tobin said:

He also mentioned the Mac.

Macs run unix these days.[/QUOTE]

Well, they *can*, but that doesn't mean that all of them *do*. The OP
(rightly) did not say which OS he was running on his Mac. Rightly, because
it is irrelevant in this newsgroup.

 

[Richard Heathfield]

pete said:

I like the added restrictions of C99,
such as no implicit int
and requiring protypes for all functions.

Likewise. Shame about the return value from main, but I stick it in anyway,
of course.

 

[Dave Vandervies]

Chris Hills said:

I didn't say "apps". I said "code".

Datum:
The code I'm currently working on at my day job breaks down as:
1399 lines of portable will-end-up-as-production code
349 lines of portable offline test drivers
60-ish lines of DLL entry points and interfacing for the live version

(The first two numbers came from wc -l, so include comments and
whitespace; the last is an estimate, since I don't have that code on
the laptop I'm using right now.)

It's not done yet, but most of the code that's yet to be written
(probably not more than another 100 lines or so; the part that does the
heavy lifting is done) will go in the first line in my summary.


dave

 

[Richard Tobin]

Macs run unix these days.

[/QUOTE]

Well, they *can*, but that doesn't mean that all of them *do*.

More than 99% of those still in use, I would guess. The newer ones
can't run pre-unix MacOS.

The OP
(rightly) did not say which OS he was running on his Mac. Rightly, because
it is irrelevant in this newsgroup.

I was not addressing the OP, just your implication that "mac" was not
covered by "unix".

-- Richard

 

[Dik T. Winter]

> Richard Tobin said:
>
> Well, they *can*, but that doesn't mean that all of them *do*.

Not even all of them *can*. And none of the Macs I have runs unix.

 

[Keith Thompson]

I think you mean ISO 9899:1990 + A1 and the TC's aka C95

C89 is a local US standard that was superseded by the ISO standard in
1990.

Yes, but the 1989 ANSI standard and the 1990 ISO standard are
virtually identical; the only differences are the section numbers and
some non-normative introductory material. A conforming C89 compiler
is a conforming C90 compiler, and vice versa.

As for C95, that raises a (possibly) interesting question. Are there
any C implementations currently in significant use that support C90
but not C95? Does the use of features introduced in C95 make code
significantly non-portable?

I don't agree there. There are few truly portable apps. However I agree
that the c standard is of little use unless the language as defined in
the standard is of use and implimentable in the majority of compilers.
Or the majority of it implimentable in All compilers.


Neither, it appears, are they wanted by the majority.

In my opinion, features defined by either the C90 or C99 standard are
perfectly appropriate for discussion here. (I don't quite share
Richard's disdain for C99.) On the other hand, it's also perfectly
appropriate to point out that certain features are defined in C99 but
not in C90 or C95, and that code that depends on C99 features is less
portable than code that doesn't. On this point, I strongly disagree
with jacob; C90 is *not* obsolete.

I'd be happier if C99 had caught on more widely, and C90 were
relegated to the same kind of historical discussion as pre-ANSI K&R C
(which is still a legitimate topic here). But that's not the reality,
and it's foolish to pretend that it is.

 

[P.J. Plauger]

Yes, but the 1989 ANSI standard and the 1990 ISO standard are
virtually identical; the only differences are the section numbers and
some non-normative introductory material. A conforming C89 compiler
is a conforming C90 compiler, and vice versa.

As for C95, that raises a (possibly) interesting question. Are there
any C implementations currently in significant use that support C90
but not C95? Does the use of features introduced in C95 make code
significantly non-portable?

Yes to both. See:

http://www.dinkumware.com/conform_c.html

It's several years old now, but still remarkably accurate. Note that
C++98 requires C95, not just C90; very few Standard C++ libraries
conform in this area, however, because they depend on the underlying
C library to deliver the goods.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Malcolm]

pete said:


Likewise. Shame about the return value from main, but I stick it in
anyway,
of course.

Implicit int was a fossil and it's time it went.
However prototypes are just a nuisance. There's some case for them in a
header file, where they describe the interface to the file, but the only
reason for them in other places is to allow the compiler to check arguments
on one pass. A modern compiler should be intelligent enough to do this
without a prototype to help it along.

 

[Malcolm]

Only by some people.

The other thing to consider is that the majority of C implimentations
are more likely to be in the embedded space (there are probably at least
4 compilers for any embedded target and dozens of targets) since AFAIK
most desktop systems have moved to C++, C# and C++/CLI etc

Also at the other end.
Parallel machines use MPI (Message Passing Interface) these days as the
standard. It comes in C or, you've guessed, it, Fortran 77. So those are the
languages I use.