C99 is widely used!
jacob navia
"There is no embedded system support", etc.
A typical message is this one of "gwowen":
gwowen a �crit :
> On Feb 24, 11:05 am, Richard <rgrd...@gmail.com> wrote:
>
>> I cant remember the time I last used a C compiler that didn't support
>> such declarations.
>
> 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":
>
> > On Feb 24, 11:05 am, Richard <rgrd...@gmail.com> wrote:
> >
> > Green Hills compiler 424 for ARM9 does not support that extension.
> > TI's compiler for their Piccolo DSP does not support that extension.
>
> 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
>
> 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 :Does 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?
Richard Heathfield
> One of the most often "arguments" against C99 in this group is that
> "There is no embedded system support", etc.
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,
especially if it means the end of this stupid subtopic, but in reality
C99 is not yet widely installed. There are, now, 10+ years after C99's
publication, a small handful of conforming compilers, but even now they
don't include Visual Studio in their number, and the installed base of
conforming compilers is a tiny fraction of that for C90.
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.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Malcolm McLean
>
> C99 is the de jure standard. When it
> becomes the de facto standard, nobody will be more pleased than me,
>
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.
Richard Heathfield
> On Feb 24, 4:04 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> 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);
Yes, but nobody is forcing anyone to /use/ VLAs, are they? What concerns
me is not poor practice, but inconsistency between the real world and
ISO. Poor practice will always be with us, but this continued
discrepancy between de facto and de jure is just darn silly and *could*
be addressed.
<snip>
> 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.
I've got all the types I need, thanks, but the existence of others does
not bother me in the slightest.
bartc
> jacob navia wrote:
>> One of the most often "arguments" against C99 in this group is that
>> "There is no embedded system support", etc.
>
> 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.
--
Bartc
Walter Banks
Richard Heathfield wrote:
> 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..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
jacob navia
> On Feb 24, 12:37 pm, jacob navia <ja...@nospam.org> wrote:
>> > 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 :Does 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
>
>
> Richard Heathfield wrote:
>
>> 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?
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
santosh wrote:
> Walter Banks <wal...@bytecraft.com> writes:
> > 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.
What features in the core C standards?
What C99 features should be left out?
gwowen
> gwowen a écrit :
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
> 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.
Richard Heathfield
> Richard Heathfield wrote:
>> jacob navia wrote:
>>> One of the most often "arguments" against C99 in this group is that
>>> "There is no embedded system support", etc.
>>
>> 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.
I avoid using C99-only features for hard-nosed pragmatic reasons of
portability. It is true that, when discussing C99 features with OPs, I
sometimes add caveats along the lines of "this won't work in C90, so
don't use it if your code needs to be C90-conforming", and I stand by
such advice. But if you're going to lay the failure of C99 at my door,
forget it. I'm simply not that influential. I know it, and realistically
I'm sure you know it too.
> 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.
I don't think anyone is arguing that position, though. If the need for
C99 features outweighs the need for portability for C90, people will use
those features, and rightly so.
Rob Kendrick
jacob navia <ja...@nospam.org> wrote:
> 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,
I bet lcc-win doesn't, either. Or are you suggesting that everybody
who downloads it uses it, and only it?
B.
Malcolm McLean
> jacob navia <ja...@nospam.org> wrote:
>
> > 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?
>
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.
Keith Thompson
> Walter Banks <wal...@bytecraft.com> writes:
>
>>
>>
>> Richard Heathfield wrote:
>>
>>> 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?
>
> 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?
> This will atleast avoid the black-and-white, binary, impression that
> many people seem to have, when considering C99.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Rob Kendrick
Malcolm McLean <malcolm...@btinternet.com> wrote:
> 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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Seebs
>> 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.
> 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!)
jacob navia
>
> 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!
Richard Heathfield
I think you misunderstand the point.
The following two paragraphs are, in part, speculation, and the
speculative parts may well not apply to you personally.
As a compiler vendor, you (presumably) frequently deal with people who
are upgrading to the latest version of your compiler. In that situation,
it is easy to fall into the trap of thinking that people are updating
their compilers every 20 minutes. In many environments, however,
compilers are used for many years before being upgraded. That's because
upgrading has a cost (and I'm not talking about the purchase price) -
cost in terms of validation, regression testing, and - in some cases -
porting. Companies aren't always too keen to pay those costs if they can
keep on using what they already have.
Another possible consequence of being a vendor is that, because you are
dealing with people who have control over their compiler choice, you
could easily make the assumption that all programmers have such control.
They don't. I have worked in many environments where I've had to put up
with the toolchain I was given...
Q: Can't I use my own tools?
A: No.
Q: But your tools are ancient! Why can't I use my own tools?
A: Software policy.
Q: But the software policy sucks!
A: Not my problem.
Frustrating, but nevertheless a reality for many programmers.
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.
--
Ian Collins
Seebs
I don't think this is a reasonable attitude to take.
If you need to use a stable version, and the stable version that you've done
all your validation on has no C99 support, then C99 support is not yet
available to you.
That said, I think it's much more important to find out whether the claim of
C99 support is intended to be part of the same claim as the 100% conformance
claim, and how much that's affected by the possible decision to declare it a
"freestanding" implementation.
jacob navia
I claim that telling
"My version of Green Hills compiler doesn't support C99" to a reader that
doesn't know the context means that there is no C99 support in those
compilers
The upgrade to C99 is 3 years old according to an official announcement of
Green Hills software. He did NOT SAY THAT, and that omission is an implicit
lie, as with heathfield, that says "it doesn't compile in my version of gcc"
without saying that is version is from 9 years ago!
Ian Collins
> Ian Collins a �crit :
>> jacob navia wrote:
>>>
>>> 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.
>>
>
> I claim that telling
>
> "My version of Green Hills compiler doesn't support C99" to a reader that
> doesn't know the context means that there is no C99 support in those
> compilers
He said "Green Hills Compiler 424" does not support those C99 features.
That's pretty explicit to me. If I were to say "gcc version 2 does
not support C99 features", would you claim that I'm saying "gcc does not
support C99 features"?
> The upgrade to C99 is 3 years old according to an official announcement of
> Green Hills software. He did NOT SAY THAT, and that omission is an
> implicit lie,
Nonsense. I've made no mention of the weather here, does that mean I've
implicitly lied about it?
--
Ian Collins
Keith Thompson
> Ian Collins a écrit :
>> jacob navia wrote:
>>>
>>> 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.
>
> I claim that telling
>
> "My version of Green Hills compiler doesn't support C99" to a reader that
> doesn't know the context means that there is no C99 support in those
> compilers
Stop using quotation marks until you understand what they mean.
gwowen did *not* write "My version of Green Hills compiler doesn't
support C99". By writing that in quotation marks, you strongly imply
that it's a direct quotation. I'm not going to say you're lying, but
you are misstating the facts.
In Message-ID
<d83a0305-7583-4dc7...@k19g2000yqc.googlegroups.com>,
in the thread "Scope of a variable declared in for loop", he actually wrote:
| 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?
The "extension" in question was the use of declarations in for
statements, such as:
for(int i=100;i>=0;i--);
> The upgrade to C99 is 3 years old according to an official announcement of
> Green Hills software. He did NOT SAY THAT, and that omission is an implicit
> lie, as with heathfield, that says "it doesn't compile in my version of gcc"
> without saying that is version is from 9 years ago!
An implicit lie? What??
jacob, seriously, you need to calm down, and you need to stop
calling people liars. There is no conspiracy. This isn't about you.
gwowen made a true and relevant statement; it is not any kind of lie,
implicit or otherwise. You owe him an apology. (You also owe me a
few; you've falsely accused me of lying on more than one occasion.)
I don't seriously expect such apologies to be forthcoming, but
*please* stop and think about what you're saying.
Rob Kendrick
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.
Rob Kendrick
Seebs <usenet...@seebs.net> wrote:
> If you need to use a stable version, and the stable version that
> you've done all your validation on has no C99 support, then C99
> support is not yet available to you.
And in fact in many situations, the compiler used is checked into
version control along with the software it is used to compile.
B.
Rob Kendrick
jacob navia <ja...@nospam.org> wrote:
> The upgrade to C99 is 3 years old according to an official
> announcement of Green Hills software. He did NOT SAY THAT, and that
> omission is an implicit lie, as with heathfield, that says "it
> doesn't compile in my version of gcc" without saying that is version
> is from 9 years ago!
Of course, not all platforms that GH 4 supported is supported by CH 5.
And that includes certain flavours of ARM.
B.
Nick Keighley
> jacob navia wrote:
> >> 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.
in the last year I've made a mod to a K&R program. I'd never actaully
used K&R before. I think the chances of many thousands of lines of
code being converted even to C89 is pretty slim!
<snip>
Flash Gordon
> On 24 Feb, 22:29, Richard Heathfield <r...@see.sig.invalid> wrote:
>> jacob navia wrote:
>
>>>> 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.
>
> in the last year I've made a mod to a K&R program. I'd never actaully
> used K&R before. I think the chances of many thousands of lines of
> code being converted even to C89 is pretty slim!
It happens. I've converted program which was many thousands of lines of
C from K&R to C90, and I've probably got it up to C99 now (not making
use of it, but valid as C99). I even converted it to using prototypes
(not available in K&R) which made the compiler point out a number of
bugs which were in the code.
--
Flash Gordon
Richard Harter
<nick_keigh...@hotmail.com> wrote:
>On 24 Feb, 22:29, Richard Heathfield <r...@see.sig.invalid> wrote:
>> jacob navia wrote:
>> > Seebs a =E9crit :
>
>> >> 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 extre=
>mely
>> >> expensive revalidation.
>
>in the last year I've made a mod to a K&R program. I'd never actaully
>used K&R before. I think the chances of many thousands of lines of
>code being converted even to C89 is pretty slim!
You would have found writing portable code in the old days rather
enlightening. There were a multiplicity of implementations with
all sorts of variations. The libraries for SYS V Unix and BSD
Unix differed in their names and contents; specific vendors had
their own additional variants. UNIX was not the whole world;
there was VMS and PRIMOS. The early PRIMOS C was particularly
charming - it was a 32 bit segmented memory machine with 48 bit
char pointers. Other pointers were 32 bits. VMS was markedly
different from UNIX. The upshot was that maintaining a product
across a wide variety of platforms was, ah, exciting. What it
came down to was that programs running on multiple platforms
ended up with lots of platform dependent conditional code.
None-the-less one could write clean, portable C code.
(Cleanliness is always a matter of debate.)
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.