What's going on with C Compilers and C99??

[Keith Thompson]

OpenWatcom is an open source C compiler. Work is ongoing to make it a
C99 compliant compiler. If you'd like to help us achieve that goal,
come over to www.openwatcom.com and join in with the development
effort. I don't think we presently make any claims about being
compliant with C99.

Who is involved in the C99 standard? As I understand it, anyone can
make a submission.

I'm not sure what you mean by a "submission". The C99 standard, as
the name implies, was completed eight years ago. There have been two
Technical Corrigenda since then, incorporated into n1124.pdf
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>. But I
don't believe there's any real work being done on a major new version
of the standard.

If you want more information about the committee, comp.std.c would be
the place to ask. New ideas are often proposed there, but there's no
offical connection between the committee and the newsgroup, and I
doubt that all the members read it.

 

[Keith Thompson]

I imagine that Turbo C 3.0 does not support C95. (It was
released in 1991.)

Ok, what about compilers currently in common use?

 

[santosh]

C90 + A1 and TC's is C95, right?

Well, a compiler that implements C95 also implements C89 (the language
defined by the 1989 ANSI standard, which is the same language as the
one defined by the 1990 ISO standard), right?

I wonder, are there any implementations (note: this includes both the
compiler and the runtime library) that support C90 but *not* C95? For
purposes of this question, consider a compiler with different
command-line options to be the same implementation.

<OT>gcc uses "--std=iso9899:199409" to specify C95 conformance.</OT>

As far as I can tell the -ansi switch for gcc is actually C95. I don't
think bare C90 is supported by gcc. Also I can't find any _commonly_
used implementation that doesn't support C95, but maybe there're
examples in the embedded or mainframe arena.

 

[Keith Thompson]

Keith Thompson wrote: [...]

I wonder, are there any implementations (note: this includes both the
compiler and the runtime library) that support C90 but *not* C95? For
purposes of this question, consider a compiler with different
command-line options to be the same implementation.

<OT>gcc uses "--std=iso9899:199409" to specify C95 conformance.</OT>

As far as I can tell the -ansi switch for gcc is actually C95. I don't
think bare C90 is supported by gcc. Also I can't find any _commonly_
used implementation that doesn't support C95, but maybe there're
examples in the embedded or mainframe arena.

With "-ansi", gcc doesn't define __STDC_VERSION__, and it doesn't
recognize digraphs, both features added in C95. With
"-std=iso9899:199409", it does.

 

[Richard Heathfield]

Keith Thompson said:

Ok, what about compilers currently in common use?

As I understand it, Turbo C 2.01 is still in common use (typically in
under-funded educational establishments).

 

[Keith Thompson]

Keith Thompson said:

As I understand it, Turbo C 2.01 is still in common use (typically in
under-funded educational establishments).

Ok, any *other* examples?

The point of my question is to determine whether it's reasonable to
assume (at least) full C95 compliance, or in other words, whether C95
code is effectively as portable (or nearly as portable) as C90 code
(i.e., as portable as C99 code isn't).

For purposes of this question, "C95" code is code that conforms to the
C95 standard and uses some of the C95 features that are not in C90;
similarly for "C99 code".

(Personally, I don't think I've never run into a need to use any of
the features that were added in C95.)

 

[Richard Heathfield]

Keith Thompson said:

Ok, any *other* examples?

Last I checked (which, admittedly, was some years ago), C/370 did not

The point of my question is to determine whether it's reasonable to
assume (at least) full C95 compliance, or in other words, whether C95
code is effectively as portable (or nearly as portable) as C90 code
(i.e., as portable as C99 code isn't).

I think the answer is probably "no".

(Personally, I don't think I've never run into a need to use any of
the features that were added in C95.)

Likewise.

 

[CBFalconer]

Keith Thompson said:
.... snip ...


I think the answer is probably "no".


Likewise.

I think that finding <iso646.h> available would indicate C95.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Default User]

Keith Thompson said:


As I understand it, Turbo C 2.01 is still in common use (typically in
under-funded educational establishments).

As we've seen recently, it seems to have some popularity with our
friends in Asia. It is a free download from Borland, and will run on
most any MS-DOS or Windows machine. I have a copy on my XP machine here
at work.

I have a lot of reasonably fond memories of this package, as I did a
lot of work in my early days on it.

Now, if you use the IDE, it seems pretty clunky these days. There are
other solutions, of course, but this is one that's out there.




Brian

 

[CBFalconer]

Richard Heathfield wrote:
.... snip ...


As we've seen recently, it seems to have some popularity with our
friends in Asia. It is a free download from Borland, and will run
on most any MS-DOS or Windows machine. I have a copy on my XP
machine here at work.

It is generally useful for checking that you haven't go any 32 bit
int dependencies left.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Richard Heathfield]

CBFalconer said:

I think that finding <iso646.h> available would indicate C95.

And its absence certainly indicates unC95ness.

The compiler I use here on my desktop system is non-C95. And a quick
check through the compilers on my legacy system (the MS-Junk box) shows
that only a couple of them have that header and therefore stand any
chance of being C95-conforming. The other half-dozen or so do not.