C99 is widely used!

[jacob navia]

One of the most often "arguments" against C99 in this group is that
"There is no embedded system support", etc.

A typical message is this one of "gwowen":

gwowen a écrit :

>
> Green Hills compiler 424 for ARM9 does not support that extension.
> TI's compiler for their Piccolo DSP does not support that extension.
>
> I use both of these these frequently. These compilers are not for
> outmoded valve powered mainframes -- ARM9's are pretty much the most
> ubiquitous microprocessors in the world. You probably have one or two
> about your immediate person.
>
> Do you ever write code for non-desktop machines?

That is a typical post. Well, if you care to investigate those claims
a bit you find immediately that they are completely WRONG. I cared to
go to Green Hills Software web site and there I found this statement from
2007:

I cite from

http://www.ghs.com/news/20070131_compiler_version5.html

that is the official site of Green Hills Software:

<quote>
Standards and Reliability

The Green Hills compiler was the first compiler for embedded systems to achieve 100% conformance to
ANSI/ISO standards for C and C++. In addition, the new compiler supports the latest C99
specification and the latest MISRA C standard. The Green Hills compilers are tested against industry
standard validation suites, including Plum Hall, and are also tested against the industry’s most
proven and extensive regression test suite.
<end quote>

That version was out in 2007!!!!

How can this guy tell us that "there is no C99 support" in Green Hills
compilers?

 

[gwowen]

One of the most often "arguments" against C99 in this group is that
"There is no embedded system support", etc.

A typical message is this one of "gwowen":

gwowen a crit :
 >
 > Green Hills compiler 424 for ARM9 does not support that extension.
 > TI's compiler for their Piccolo DSP does not support that extension.

How can this guy tell us that "there is no C99 support" in Green Hills
compilers?

I didn't, as anyone with even basic reading comprehension will
understand. I said "Green Hills Compiler 424" does not support that
construct. I was very, very specific, and as such I wrote somGreen
Hills Compiler v5 is a considerably more expensive, and a licence for
that is not available to me. I use Green Hills version 424. That's
what I was talking about it, and I couldn't have been more specific if
I'd tried. Would that you used the same accuracy in reading.

How can this guy tell us that "there is no C99 support" in Green Hills
compilers?

Please do not put quotes around phrases that are not quotes. It's
extremely dishonest. As is apparent from the text you quoted *I said
no such thing* and I'd appreciate it if you withdrew the insinuation
that I did. Otherwise you'll look like a stubborn fool, rather than
just a fool.

 

[gwowen]

 > TI's compiler for their Piccolo DSP does not support that extension.

That is a typical post. Well, if you care to investigate those claims
a bit you find immediately that they are completely WRONG.

Oooh, I like a challenge.

Here's a bit of the TI web page, that I notice you did not comment on:
------------------------------------------------------------------------
http://tiexpressdsp.com/index.php/TI_Compilers_and_Industry_Standards

Question oes the (current) C/C++ compiler comply to any norm (ISO,
IEEE)?
Answer: All TI compilers support:
* C Standard: ANSI X3.159-1989 (C89), which is the same as ISO/IEC
9899:1990.
* C++ Standard: ISO/IEC 14882:1998

We do not support: C95, C99, C++ 2003, C++ TR1.
Though we do support, as language extensions, some C99 features. Two
examples are the restrict keyword, and the header file stdint.h.
-------------------------------------------------------------------------

So of my two examples I was completely RIGHT on both. Neither of the
compilers I mentioned support the feature I mentioned -- a later
version of one does, but the latest version of the TI compiler still
does not.

Any comment Jake, you crazy bastard?

 

[Malcolm McLean]

C99 is the de jure standard. When it
becomes the de facto standard, nobody will be more pleased than me,

I won't be too happy.
The idea of a fast stack allocator is a good one. But it must be
allowed to fail if the stack is too small. So the sensible
implentation is
void *ptr = salloc(N);
(ptr is null on failure)
rather than
array[N];
(undefined behaviour if N is too large);

Also, some holes in C89 were never addressed.
There's still no way to build a variable argument list at runtime.
There's still no way of creating a user-defined FILE stream.
There's no way of defining the failure behaviour of malloc(), or of
overriding malloc's allocation strategy.

My other nit is that the number of types has grown too large. The
number of interconversions is O(N^2), so a growth from a tiny handful
to a dozen or so is really quite significant.

 

[bartc]

One of the biggest flaws in your "argument" is that there is some kind
of anti-C99 campaign. There isn't. C99 is the de jure standard. When
it becomes the de facto standard, nobody will be more pleased than me,

And of course the best way for that to happen is to deliberately avoid using
C99 features, and recommend others to do the same, which is hardly incentive
for compiler vendors to give C99 compatibility any priority, as there is no
competitive reason to do so.

If no-one should use C99 until every compiler for every platform in the
world can support it 100% (not 99.9%, but 100%) then I just can't see how it
can take off.

 

[Walter Banks]

At least nearly-everybody, and possibly everybody, agrees with you that
C99 is the One and Only C Standard, and that C90 is Legally Dead.
Nevertheless, it is C90 that is doing most of the actual work.

It may be a C90 based compilers with and without C99 extensions.
Most of the C90 based compilers today have a significant amount of C99
as part of the feature set and standard libraries.

In the embedded system world C99 brought a lot of order into "one of"
compiler specific feature sets that existed. A bigger debate is should C
have a feature set core with application area extensions?


Regards,


Walter..

 

[jacob navia]

gwowen a écrit :

Oooh, I like a challenge.

Here's a bit of the TI web page, that I notice you did not comment on:
------------------------------------------------------------------------
http://tiexpressdsp.com/index.php/TI_Compilers_and_Industry_Standards

Question oes the (current) C/C++ compiler comply to any norm (ISO,
IEEE)?
Answer: All TI compilers support:
* C Standard: ANSI X3.159-1989 (C89), which is the same as ISO/IEC
9899:1990.
* C++ Standard: ISO/IEC 14882:1998

We do not support: C95, C99, C++ 2003, C++ TR1.
Though we do support, as language extensions, some C99 features. Two
examples are the restrict keyword, and the header file stdint.h.

That page conerns the TI DSP stuff, that I did not question. You are
just answering to something I did NOT say

With a reason. I spoke about the Green Hills software compilers. You
answer with TI compilers.

So of my two examples I was completely RIGHT on both.

No. Green Hills upgraded to C99 3 years ago. That you are broke and
can't afford the new version has nothing to do with C99 support.

You can use gcc-1.0, but then, you can't argue that gcc doesn't support
C++ or C99. What counts is the version ABAILABLE. Besides, that version
is already 3 years old. Enough time to upgrade.

Neither of the
compilers I mentioned support the feature I mentioned -- a later
version of one does, but the latest version of the TI compiler still
does not.

Ans so what? That is an old small embedded processor that surely
doesn't support the full standard of C89 because the run time must
fit in a very small RAM place. Functions like double arithmetic or long
double are probably absent.

Any comment Jake, you crazy bastard?

I did NOT insult you. You are the one insulting here because
you have NO ARGUMENTS at all.

 

[santosh]

It may be a C90 based compilers with and without C99 extensions.
Most of the C90 based compilers today have a significant amount of
C99 as part of the feature set and standard libraries.

In the embedded system world C99 brought a lot of order into "one
of" compiler specific feature sets that existed. A bigger debate is
should C have a feature set core with application area extensions?

It seems to be the way to go for future C standards, if they don't
want to be painted with the C99 brush. Some common subset of C90 and
C99 could serve as the "core" language, and other features specified
as extensions.

This will atleast avoid the black-and-white, binary, impression that
many people seem to have, when considering C99.

 

[Walter Banks]

It seems to be the way to go for future C standards, if they don't
want to be painted with the C99 brush. Some common subset of C90 and
C99 could serve as the "core" language, and other features specified
as extensions.

This will atleast avoid the black-and-white, binary, impression that
many people seem to have, when considering C99.

What features in the core C standards?

What C99 features should be left out?

Regards,


Walter..

 

[gwowen]

gwowen a écrit :








That page conerns the TI DSP stuff, that I did not question. You are
just answering to something I did NOT say

With a reason. I spoke about the Green Hills software compilers. You
answer with TI compilers.


No. Green Hills upgraded to C99 3 years ago. That you are broke and
can't afford the new version has nothing to do with C99 support.

You can use  gcc-1.0, but then, you can't argue that gcc doesn't support
C++ or C99. What counts is the version ABAILABLE. Besides, that version
is already 3 years old. Enough time to upgrade.


Ans so what? That is an old

No it isn't. The Piccolo is barely out of the fab plants. It's low
cost, but its new.

small embedded processor that surely
doesn't support the full standard of C89 because the run time must
fit in a very small RAM place.

Wrong. You can get them with a lot of RAM, and a lot of flash.

Functions like double arithmetic or long
double are probably absent.

No. You can look this stuff you know. True, its not as easy as
making stuff up, but you'll find there's a closer correlation to
reality. Those features are slow, and emulated in software by the
runtime library, but they're there.

Allow me to requote TI's specs, since you seemed to overlook them:

****** All TI compilers support: C Standard: ANSI X3.159-1989 (C89)
******

I did NOT insult you. You are the one insulting here because
you have NO ARGUMENTS at all.

I made a true claim about Green Hills 4.2.4. This is not true of
Green Hills v5, but it is true of Green Hills 4.2.4 which I, (and I am
sure many other people) still use.

Care to have a wager which is more widely used today: GSH 4.2.4 or lcc-
win, every version other than that supported with MathWorks?

I made a true claim about TI's embedded compiler, which seem to have
chosen to ignore, because it clashes with you prejudices.

You made some untrue claims about my true claims, and then invented
some further claims (which I never made). I would like you to retract
those claims, please.

Here are my claims again:
i) TI's widely used compiler does not support many features of C99.
ii) Green Hills 4.2.4, another compiler used by far more people than
will ever use lcc-win in its entire existence, does not support many
features of C99.

If you can't refute either of those claims -- which is all I've ever
said -- please don't bother replying, you crazy bastard.

 

[jacob navia]

gwowen a écrit :

Here are my claims again:
i) TI's widely used compiler does not support many features of C99.
ii) Green Hills 4.2.4, another compiler used by far more people than
will ever use lcc-win in its entire existence, does not support many
features of C99.

Mmmm, lcc-win passed the million downloads a year ago. There are
thousands of downloads in a week... I would bet that an old
version of Green Hills doesn't have that kind of usage, since it
costs US$ 1500. Selling 1000/week would make 1.5 million US$ per
week in compiler sales, around 6 million/month...

Too much to be true.

But anyway, the discussion here was not that you can't
upgrade because US$ 1500 is too much for you. The fact
is that an upgrade path EXISTS and C99 is supported.

 

[Rob Kendrick]

gwowen a écrit :

Mmmm, lcc-win passed the million downloads a year ago. There are
thousands of downloads in a week... I would bet that an old
version of Green Hills doesn't have that kind of usage,

I bet lcc-win doesn't, either. Or are you suggesting that everybody
who downloads it uses it, and only it?

B.

 

[Keith Thompson]

It seems to be the way to go for future C standards, if they don't
want to be painted with the C99 brush. Some common subset of C90 and
C99 could serve as the "core" language, and other features specified
as extensions.

So the "core" would be C90 minus implicit int and the ability to use
"restrict" and "inline" as identifiers? (gets() and non-prototype
function declarations could probably also be dropped from the core.)

I'm not comfortable with that idea. If C201X takes the traditional
monolithic approach, I can count on any conforming implementation to
support all language features. If most features beyond C90 are
optional, then the implementer gets to decide whether I can use those
features.

If I want to use <complex.h>, I can use compiler X. If I want to use
<threads.h> (a feature proposed for C201X), I can use compiler Y. If
I want both I may well be out of luck.

Which is pretty much the current situtation with C99. Most compilers
implement all of C90. Many implement some subset of C99-specific
features, but the subset varies from one implementation to another.
The only difference is that the subsets are defined by each
implementation, not by the standard.

If getting all implementers to support the entire language is an
unrealistic goal, the subset approach might be a necessary compromise,
but I hope it isn't.

Or do I misunderstand what you're proposing?

 

[Malcolm McLean]

I bet lcc-win doesn't, either.  Or are you suggesting that everybody
who downloads it uses it, and only it?

The problem with giving stuff away for free is that you don't know who
is actually using it. If you charge then it's much more likely that
purchasers will also be users.
However downloads will bear some relationship to usage. A project with
thousands of downloads a week is clearly a success.

 

[Rob Kendrick]

However downloads will bear some relationship to usage. A project with
thousands of downloads a week is clearly a success.

Absolutely, I just wanted to point out that it has very little
relationship to people currently using it.

A project I'm involved in gets hundreds of downloads a week, and yet I
can't think there are more than a thousand people interested in it at
all.

B.

 

[Seebs]

That is a typical post. Well, if you care to investigate those claims
a bit you find immediately that they are completely WRONG. I cared to
go to Green Hills Software web site and there I found this statement from
2007:

I find it surprising.

The Green Hills compiler was the first compiler for embedded systems to achieve 100% conformance to
ANSI/ISO standards for C and C++. In addition, the new compiler supports the latest C99
specification and the latest MISRA C standard.

Interesting. I wonder which compiler they're using for C99. I had not heard
of anyone passing C99 tests.

That version was out in 2007!!!!

How can this guy tell us that "there is no C99 support" in Green Hills
compilers?

Possibly relevant:
1. Embedded systems are quite often billed as "freestanding", meaning they
don't have to have a working standard library -- and that's where a lot of
the work goes.
2. If you read that carefully, technically it never claims to be 100%
conformant to the CURRENT standard. "Was the first..." could mean that,
in 1992 or so, they achieved 100% conformance to the ISO standard for C,
before any other embedded compiler had done so. And that, now, they support
C99 -- but not with 100% conformance.
3. I do not, in general, trust the marketing blurbs produced by vendors.

I know that we have occasionally had issues with marketing making claims
which were not what we told them, but which were similar enough to a layman
that I do not suspect malice.

-s

 

[Seebs]

gwowen a écrit :

No. Green Hills upgraded to C99 3 years ago. That you are broke and
can't afford the new version has nothing to do with C99 support.

It does for other people who might be using the same compiler.

You can use gcc-1.0, but then, you can't argue that gcc doesn't support
C++ or C99. What counts is the version ABAILABLE. Besides, that version
is already 3 years old. Enough time to upgrade.

In embedded systems, it's quite common to stick with a stable, known, version
for 3-5 years, or even 10, because changes would require extremely expensive
revalidation.

Ans so what? That is an old small embedded processor that surely
doesn't support the full standard of C89 because the run time must
fit in a very small RAM place. Functions like double arithmetic or long
double are probably absent.

Probably not. Keep in mind that most embedded targets are freestanding,
meaning they'll tend to have most of the underlying language features,
but not always all. (Note that stdint.h and restrict are, by the way, both
things that can be implemented purely by adding headers or keyword parsing,
with NO additional compilation logic and NO additional runtime!)

-s

 

[jacob navia]

Seebs a écrit :

In embedded systems, it's quite common to stick with a stable, known, version
for 3-5 years, or even 10, because changes would require extremely expensive
revalidation.

OK. If you do not want the newer version do not use it. But then, please
do not complain that the compiler has no C99 support!

 

[Rob Kendrick]

OK. If you do not want the newer version do not use it. But then,
please do not complain that the compiler has no C99 support!

It may be that there /is/ no newer compiler, and to get C99 support,
one would have to move to a different vendor. Been there, done that.

Or, in the sake of BeOS, they are stuck on GCC 2.95 due to C++ ABI
issues. Thus no C99 there, either. (At least, not without lots of
faffing.)

B.

 

[Ian Collins]

How can this guy tell us that "there is no C99 support" in Green Hills
compilers?

He didn't. He correctly stated that version 4 of their complier doesn't
support C99.

You should retract your false claim.