I have access to a wide variety of different platforms here at JPL
and they all have pretty good C 99 compilers.
Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?
Nov 14 '05
233  8110 
Mabden wrote:
[ that he does not like to see E. Robert Tisdale called a troll ]
It seems to me that you can't have been reading this newsgroup very
long, or very carefully.
Of the messages I've seen, saying "So-and-so is a troll, disregard
him", over the last year or so, most have been from ERT himself, and
mostly they have been very silly: a troll accusation issued when
somebody says something he disagrees with.
ERT's latest foray strikes me as a case of (at least mild)
trolling. Not long ago here there was a serious discussion of the
shortcomings of C99 and the fact that mainstream C compilers do not
support it and do not seem in any hurry to support it. Then ERT
comes along and says, all innocent and without reference to the
previous discussion, "Hey, on my system I have a bunch of compilers
that support C99, why isn't everyone using it? Are they just
dragging their feet?"
Allin Cottrell
"Allin Cottrell" <co******@wfu.edu> wrote in message
news:ch***********@f1n1.spenet.wfu.edu... Mabden wrote:
[ that he does not like to see E. Robert Tisdale called a troll ]
ERT's latest foray strikes me as a case of (at least mild)
trolling. Not long ago here there was a serious discussion of the
shortcomings of C99 and the fact that mainstream C compilers do not
support it and do not seem in any hurry to support it. Then ERT
comes along and says, all innocent and without reference to the
previous discussion, "Hey, on my system I have a bunch of compilers
that support C99, why isn't everyone using it? Are they just
dragging their feet?"
Yes I saw that. He claims to work at JPL and has access to many machines of
all kinds that support C99.
I read how some people feel that C99 is not implemented as widely as it
should be. So what is wrong with all the C99 compiler implementations in
your view?
--
Mabden
Mabden wrote:
.... snip ...
I read how some people feel that C99 is not implemented as widely
as it should be. So what is wrong with all the C99 compiler
implementations in your view?
Back when C89/90 appeared, it was preceded by the appropriate
drafts. The prime market for C (and other) compilers then was
DOS. Among the main competitors were MS, Borland, Zortech,
Watcom, selling roughly in the $200 .. $1000 range. There had
been no standard, and the users demanded standards compliance.
There was fun and profit in supplying that demand.
Today by far the majority of C is developed on either GCC or MS
VC. Only gcc is making an effort to be C99 compliant, on
principle. There is no profit in it, and no overwhelming user
demand, thus no pressure. There is a relatively small market for
embedded cross compilers, some of which still sell for exorbitant
numbers. The chips their output runs on are often incapable of
handling a fully compliant C system, so the compilers do funny and
specialized things. Again, no pressure.
A third factor is the GUI. They are inherently system specific
and have been deliberately made incompatible with standard
practice (at least in the case of MS, i.e. use of winmain, no
stdin/stdout). MS has no great interest in portable code.
15, 20, 25 years ago a good compiler, for any fairly popular
language or close approximation could earn the writer a good
living. Not so today.
--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
On Wed, 01 Sep 2004 06:03:02 GMT
"Mabden" <mabden@sbc_global.net> wrote: "Allin Cottrell" <co******@wfu.edu> wrote in message
news:ch***********@f1n1.spenet.wfu.edu... Mabden wrote:
[ that he does not like to see E. Robert Tisdale called a troll ]
ERT's latest foray strikes me as a case of (at least mild)
trolling. Not long ago here there was a serious discussion of the
shortcomings of C99 and the fact that mainstream C compilers do not
support it and do not seem in any hurry to support it. Then ERT
comes along and says, all innocent and without reference to the
previous discussion, "Hey, on my system I have a bunch of compilers
that support C99, why isn't everyone using it? Are they just
dragging their feet?"
Yes I saw that. He claims to work at JPL and has access to many
machines of all kinds that support C99.
I read how some people feel that C99 is not implemented as widely as
it should be. So what is wrong with all the C99 compiler
implementations in your view?
The fact that they don't exist?
Seriously, only a very few of the implementations used by people other
than ERT claim C99 conformance but nearly all of them claim C89
conformance when invoked correctly.
MS have stated that they do not intend to implement C99 thus eliminating
a significant (although not necessarily the largest) part of the market.
gcc has not fully implemented the language parts of C99 (the libraries
are separate) thus eliminating another large segment.
I currently develop SW for 4 OSs and don't have even 1 C99 compliant
compiler. Admittedly 3 of those are *nix, but I am including both native
compilers and gcc on all the systems in my count.
Also, you should note that ERT has not told us what these compilers are
that he claims to have that support C99. Since he won;t tell us the
claim cannot be verified and is therefor highly suspect.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
In <qC*****************@newssvr27.news.prodigy.com> "Mabden" <mabden@sbc_global.net> writes: "Allin Cottrell" <co******@wfu.edu> wrote in message
news:ch***********@f1n1.spenet.wfu.edu... Mabden wrote:
[ that he does not like to see E. Robert Tisdale called a troll ]
ERT's latest foray strikes me as a case of (at least mild)
trolling. Not long ago here there was a serious discussion of the
shortcomings of C99 and the fact that mainstream C compilers do not
support it and do not seem in any hurry to support it. Then ERT
comes along and says, all innocent and without reference to the
previous discussion, "Hey, on my system I have a bunch of compilers
that support C99, why isn't everyone using it? Are they just
dragging their feet?"
Yes I saw that. He claims to work at JPL and has access to many machines of
all kinds that support C99.
If you're not a patent idiot (or a troll on your own) you must be an
alternate net identity of Tisdale. ERT has explicitly admitted, in a
subsequent post, that none of the compilers he has access to is a
conforming C99 compiler, they merely support all the C99 features *he*
needs. This doesn't make them C99 compilers and this is far from
justifying the usage of C99 features in *portable* C code (which
happens to be the main focus of this newsgroup).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On Wed, 01 Sep 2004 06:03:02 GMT, "Mabden" <mabden@sbc_global.net>
wrote: "Allin Cottrell" <co******@wfu.edu> wrote in message
news:ch***********@f1n1.spenet.wfu.edu... Mabden wrote:
[ that he does not like to see E. Robert Tisdale called a troll ]
ERT's latest foray strikes me as a case of (at least mild)
trolling. Not long ago here there was a serious discussion of the
shortcomings of C99 and the fact that mainstream C compilers do not
support it and do not seem in any hurry to support it. Then ERT
comes along and says, all innocent and without reference to the
previous discussion, "Hey, on my system I have a bunch of compilers
that support C99, why isn't everyone using it? Are they just
dragging their feet?"
Yes I saw that. He claims to work at JPL and has access to many machines of
all kinds that support C99.
Did he name those machines, and the C99 implementations that he claims
exist?
I read how some people feel that C99 is not implemented as widely as it
should be. So what is wrong with all the C99 compiler implementations in
your view?
Mostly that with few exceptions, they don't exist. The only compiler
I'm aware of which claims C99 conformance is Comeau, though many
compilers provide support for some of the features. The probability is
that Mr. Tisdale doesn't know what he's talking about, or is simply
trolling, or both. We have seen many examples of all three cases.
--
Al Balmer
Balmer Consulting re************************@att.net
In article <ch**********@nntp1.jpl.nasa.gov>, E. Robert Tisdale
<E.**************@jpl.nasa.gov> writes Malcolm wrote:
The difference is that C99 was designed by a standards body.
There is no point in having a "standard" that is not widely implemented.
So the present situation is very undesireable, but it is largely ANSI's fault,
because the extensions were neither so minimal that they could be
trivially implemented (a #define for bool, a vnsprintf() function, etc)
nor were like the C++ extensions,
very far reaching and offering greatly enhanced functionality.
Instead, we had a lot of feature of dubious use
which require rewrites of the compiler.
For instance, variables can now be declared anywhere which seems to be
just a way of making code less organised and harder to read,
and variable arrays are allowed.
Since a variable length array cannot fail,
and the programmer won't know the array length at run time,
this is asking for a security exploit.
Your indictment of ANSI
It was not an indictment of ANSI.... ANSI is only one of a large number
of National Bodies that make up the ISO WG14 who produce the C standard.
seems to imply that
it is taking a lot longer for C compiler developers to implement
the C99 standard than it took to implement the C89 standard
and that the blame for the delay belongs [mostly] with ANSI
and *not* with the C compiler developers.
Well ISO have produced the standard the compiler writers have to work
to. The simpler the standard the easier it is to do.
The compiler writers are (on the whole) commercial if the world really
demanded a C99 compiler the would be more likely to do them faster.
I think it is the complexity coupled with the lack of requirement for a
C99 compiler that is the problem. If there was an industrial/commercial
requirement that we all use C99 compilers they would all be C99
compilers.
There is no black and white in this.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills wrote: IE. Robert Tisdale writes
Malcolm wrote:
The difference is that C99 was designed by a standards body.
There is no point in having a "standard" that is not widely implemented.
So the present situation is very undesireable, but it is largely ANSI's fault,
because the extensions were neither so minimal that they could be
trivially implemented (a #define for bool, a vnsprintf() function, etc)
nor were like the C++ extensions,
very far reaching and offering greatly enhanced functionality.
Instead, we had a lot of feature of dubious use
which require rewrites of the compiler.
For instance, variables can now be declared anywhere which seems to be
just a way of making code less organised and harder to read,
and variable arrays are allowed.
Since a variable length array cannot fail,
and the programmer won't know the array length at run time,
this is asking for a security exploit.
Your indictment of ANSI
It was not an indictment of ANSI....
ANSI is only one of a large number of National Bodies
that make up the ISO WG14 who produce the C standard.
Malcolm mentions only ANSI.
What fraction of the blame belongs to these other "National Bodies"?
And who are they?
seems to imply that
it is taking a lot longer for C compiler developers to implement
the C99 standard than it took to implement the C89 standard
and that the blame for the delay belongs [mostly] with ANSI
and *not* with the C compiler developers.
Well, ISO [has] produced the standard
[that] the compiler writers [must] work to.
The simpler the standard the easier it is to do.
The compiler writers are, on the whole, commercial. If the world really
demanded a C99 compiler, they would be more likely to do them faster.
So the "world" is to blame for the delay in full compliance?
I think it is the complexity coupled with
the lack of requirement for a C99 compiler that is the problem.
If there was an industrial/commercial requirement
that we all use C99 compilers, they would all be C99 compilers.
So C99 is the standard that nobody wanted?
In <uV**************@phaedsys.demon.co.uk> Chris Hills <ch***@phaedsys.org> writes: I think it is the complexity coupled with the lack of requirement for a
C99 compiler that is the problem. If there was an industrial/commercial
requirement that we all use C99 compilers they would all be C99
compilers.
You can safely drop the complexity bit from the picture: two tiny
businesses, Comeau and Dinkumware have produced an implementation
claiming C99 conformance since quite a while. The bigger vendors could
have done it a lot faster.
The real reasons are:
1. Lack of interest from the C community at large. The development of
C99 was mostly politically driven and little attention was paid to
what the C programmers actually needed/wanted. GNU C extensions of
proven value have been completely ignored, but we've got plenty of
Fortran features with little relevance to the main C problem domains.
2. C99 features conflicting with existing C89 extensions of many
implementors. The implementors are reluctant to break their users'
code by implementing the C99 semantics of the same feature. See an
older discussion about why GNU C people don't want to change their
compiler according to C99. gcc got quite close to C99 conformance
when version 3.0 was released (over three years ago), but didn't make
any significant progress ever since...
As a result, most implementations have C99 extensions, but this doesn't
help people writing portable code, as there is no commonly supported
subset of C99 (with the possible exception of // comments).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
E. Robert Tisdale wrote: Chris Hills wrote:
.... Malcolm mentions only ANSI.
What fraction of the blame belongs to these other "National Bodies"?
ANSI has always played a disproportionately large role in the
development of the C standard, but I don't know how to determine a hard
number describing that disproportion.
And who are they?
The ISO C committee membership consists of representatives of various
"National Bodies" - each one is responsible for technical standards in
one nation, just as ANSI responsible for technical standards for the
United States.
.... The compiler writers are, on the whole, commercial. If the world really
demanded a C99 compiler, they would be more likely to do them faster.
So the "world" is to blame for the delay in full compliance?
Yes. By "the world", what is meant is people who purchase compilers. If
those people really demanded C99 compliance, and refused to purchase
non-compliant compilers, the compiler vendors would rush to accommodate
them. Since there's been no strong demand for C99 compliance, it has
come far more slowly.
In article <ch**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote: 2. C99 features conflicting with existing C89 extensions of many
implementors. The implementors are reluctant to break their users'
code by implementing the C99 semantics of the same feature. See an
older discussion about why GNU C people don't want to change their
compiler according to C99. gcc got quite close to C99 conformance
when version 3.0 was released (over three years ago), but didn't make
any significant progress ever since...
Such conflicts are not a significant obstruction to C99 support in
GCC. Where problems arise, compatibility with old extensions
conflicting with C99 syntax is preserved under -std=gnu89. (For
example, certain uses of compound literals not permitted by C99 are
permitted with -std=gnu89. If C99 inline is implemented, that is
another case where -std=gnu89 would preserve the old semantics.)
When C99 features or other conformance improvements have been added to
GCC over the last four years has been largely determined by when I
have been able to work on implementing them and by the lack of any
funding for C99 or conformance implementation.
To answer some of the other suggestions made about missing and
incomplete C99 support in GCC:
There are no technical difficulties in preserving compatibility with
existing documented and undocumented extensions under appropriate
options, and in maintaining support for past C standard versions under
appropriate options (-std=iso9899:1990, -std=iso9899:199409,
-std=iso9899:1999). (GCC is not following the route apparently
followed by some implementations of abandoning support for older and
more widely used standard versions, nor is it abandoning extensions
without careful individual consideration.)
There are no technical difficulties in supporting C99 through
incremental changes within the current infrastructure.
There are no political objections to supporting the actual standard
rather than drafts.
It may not always be obvious whether a particular ill-designed
extension (documented or undocumented) is something that should be
kept, for compatibility with existing code or because it supports
something that can't be done within the standard, but this is dealt
with, whether or not the extension conflicts with C99, by taking care
to understand the extensions, documented or undocumented, implemented
by compiler code before changing it, so as to avoid removing
extensions by accident, discussing appropriately before removing
extensions and normally deprecating extensions for a release before
removing them if it is thought they may have a significant number of
users. Extensions are not any longer generally liked unless they add
expressive power to the language (e.g., to do machine-dependent things
which standard C cannot do) but consideration for existing users means
we take this care to stay compatible and only remove extensions with
due warning and where they cause trouble for the implementation.
--
Joseph S. Myers js***@gcc.gnu.org
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:ch**********@nntp1.jpl.nasa.gov...
The compiler writers are, on the whole, commercial. If the world really
demanded a C99 compiler, they would be more likely to do them faster.
So the "world" is to blame for the delay in full compliance?
Essentially, yes. The 'market' is to 'blame'. If there's
little or no demand for something, there's not much return for
resources expended in creating it. I think it is the complexity coupled with
the lack of requirement for a C99 compiler that is the problem.
If there was an industrial/commercial requirement
that we all use C99 compilers, they would all be C99 compilers.
So C99 is the standard that nobody wanted?
Seems that way. At least so far. If someone were to prove
unequivocably that they gained a significant increase in
productivity and/or quality as a direct result of using
C99 instead of C89, in more than a narrow application niche,
then I'd expect folks would have more interest in seeing C99
more widely implemented.
-Mike
"Dan Pop" <Da*****@cern.ch> wrote in message
news:ch**********@sunnews.cern.ch... In <qC*****************@newssvr27.news.prodigy.com> "Mabden"
<mabden@sbc_global.net> writes:"Allin Cottrell" <co******@wfu.edu> wrote in message
news:ch***********@f1n1.spenet.wfu.edu... Mabden wrote:
[ that he does not like to see E. Robert Tisdale called a troll ]
ERT's latest foray strikes me as a case of (at least mild)
trolling. Not long ago here there was a serious discussion of the
shortcomings of C99 and the fact that mainstream C compilers do not
support it and do not seem in any hurry to support it. Then ERT
comes along and says, all innocent and without reference to the
previous discussion, "Hey, on my system I have a bunch of compilers
that support C99, why isn't everyone using it? Are they just
dragging their feet?"
Yes I saw that. He claims to work at JPL and has access to many machines
ofall kinds that support C99.
If you're not a patent idiot (or a troll on your own) you must be an
alternate net identity of Tisdale.
Ummm... I guess the first one? But I was never patented, so copies of my
idiocy may be reused and distributed freely. BTW, you snipped the bit where
I said someone would call me a troll and / or a sock puppet - are you trying
to appear original, because you are quite predictable.
ERT has explicitly admitted, in a
subsequent post, that none of the compilers he has access to is a
conforming C99 compiler, they merely support all the C99 features *he*
needs. This doesn't make them C99 compilers and this is far from
justifying the usage of C99 features in *portable* C code (which
happens to be the main focus of this newsgroup).
OK, so the "main focus" of this newsgroup is a compiler that doesn't exist?
And the one man who says he has one is ridiculed by all those who don't have
a C99 compiler?
If I admit I feel stupid, will you explain that to me, please?
And, please, TRY to be nicer once in a while.
--
Mabden
"Mabden" <mabden@sbc_global.net> wrote in message
news:_x******************@newssvr27.news.prodigy.c om... "Dan Pop" <Da*****@cern.ch> wrote in message
news:ch**********@sunnews.cern.ch... In <qC*****************@newssvr27.news.prodigy.com> "Mabden" <mabden@sbc_global.net> writes:
ERT has explicitly admitted, in a
subsequent post, that none of the compilers he has access to is a
conforming C99 compiler, they merely support all the C99 features *he*
needs. This doesn't make them C99 compilers and this is far from
justifying the usage of C99 features in *portable* C code (which
happens to be the main focus of this newsgroup).
OK, so the "main focus" of this newsgroup is a compiler that doesn't
exist?
That's not what he said. He said the main focus is "*portable* C code."
I agree with that.
And the one man who says he has one is ridiculed by all those who don't
have a C99 compiler?
IMO the ridicule is because of his reputation here. Again, note
that he did not enumerate the 'C99 compliant' implementations he has,
so nobody can verify or disprove his claim.
If I admit I feel stupid, will you explain that to me, please?
And, please, TRY to be nicer once in a while.
Dan is Dan. He does seem to rub many folks the wrong way, but
in light of his demonstrated knowledge, I'm glad he's here.
-Mike
Joseph Myers wrote:
.... snip ...
When C99 features or other conformance improvements have been
added to GCC over the last four years has been largely determined
by when I have been able to work on implementing them and by the
lack of any funding for C99 or conformance implementation.
.... snip ...
Excellent. One thing that annoys me (please correct if I am
wrong) is that I understand gcc requires the gnu extensions to
compile itself. It would be a great boost to portability if it
required nothing more than C89 compliance.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
CBFalconer <cb********@yahoo.com> writes: Excellent. One thing that annoys me (please correct if I am
wrong) is that I understand gcc requires the gnu extensions to
compile itself. It would be a great boost to portability if it
required nothing more than C89 compliance.
You are partly right. From http://gcc.gnu.org/install/prerequisites.html:
Tools/packages necessary for building GCC
ISO C90 compiler
Necessary to bootstrap the GCC package, although versions of
GCC prior to 3.4 also allow bootstrapping with a traditional
(K&R) C compiler.
To make all languages in a cross-compiler or other
configuration where 3-stage bootstrap is not performed, you
need to start with an existing GCC binary (version 2.95 or
later) because source code for language frontends other than
C might use GCC extensions.
So you need GCC to compile GCC if you're cross-compiling, but not
otherwise.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
E. Robert Tisdale wrote: So C99 is the standard that nobody wanted?
Actually quite a lot of the new stuff in C99 was in
response to "customer" demand. But since it is
almost entirely compatible with C89, there isn't
as much a sense of urgency to get it implemented as
there was for the initial standard. There are C99
implementations (at least they purport to be; I
haven't validated them), and much of the new stuff
has been implemented in not-yet-fully-C99-compliant
implementations. We chose to reaffirm the current
standard for the next several years rather than
work on a major revision, in order to provide more
stability while the transition occurs.
On Wed, 01 Sep 2004 20:55:25 -0700 in comp.std.c, Ben Pfaff
<bl*@cs.stanford.edu> wrote: CBFalconer <cb********@yahoo.com> writes:
Excellent. One thing that annoys me (please correct if I am
wrong) is that I understand gcc requires the gnu extensions to
compile itself. It would be a great boost to portability if it
required nothing more than C89 compliance.
You are partly right. From http://gcc.gnu.org/install/prerequisites.html:
Tools/packages necessary for building GCC
ISO C90 compiler
Necessary to bootstrap the GCC package, although versions of
GCC prior to 3.4 also allow bootstrapping with a traditional
(K&R) C compiler.
To make all languages in a cross-compiler or other
^^^ configuration where 3-stage bootstrap is not performed, you
need to start with an existing GCC binary (version 2.95 or
later) because source code for language frontends other than
^^^^^^^^^^ C might use GCC extensions.
So you need GCC to compile GCC if you're cross-compiling, but not
otherwise.
ISTM that only applies to cross-compiling languages other than C.
IIRC GNU C conditionalizes GCC extensions to allow other compilers to
bootstrap GCC: whereas GNU C may take advantage of GCC extensions if
compiled by GCC, it appears that GNU Ada, C++, Fortran, Java, Pascal
may rely on GCC extensions.
It also seems that as of GCC 3.4, K&R compilers are not supported and
ISO compilers are now required to port GCC. Providing 15 years
transition is pretty reasonable. Looks like GCC 3.3 may be a keeper
for supporting traditional platforms, and providing a transition to
newer versions.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Br**********@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
According to Mike Wahler <mk******@mkwahler.net>: If someone were to prove unequivocably that they gained a significant
increase in productivity and/or quality as a direct result of using
C99 instead of C89
My company writes cryptographic-related code and my own RSA code is
made much faster by the use of the "unsigned long long" type which
C99 provides, but not C89. Several implementations had the "long
long" before C99, but C99 gives me the guarantee that ultimately, all
compilers which will provide "long long" will do it in a way which is
compatible with C99. This increases portability.
--Thomas Pornin
"Mabden" <mabden@sbc_global.net> wrote in message news:<_x******************@newssvr27.news.prodigy. com>... "Dan Pop" <Da*****@cern.ch> wrote in message
news:ch**********@sunnews.cern.ch...
.... needs. This doesn't make them C99 compilers and this is far from
justifying the usage of C99 features in *portable* C code (which
happens to be the main focus of this newsgroup).
OK, so the "main focus" of this newsgroup is a compiler that doesn't exist?
No, he said it was "portable code", not "a compiler".
In comp.std.c James Kuyper <ku****@saicmodis.com> wrote:
Yes. By "the world", what is meant is people who purchase compilers. If
those people really demanded C99 compliance, and refused to purchase
non-compliant compilers, the compiler vendors would rush to accommodate
them. Since there's been no strong demand for C99 compliance, it has
come far more slowly.
There's also essentially no competition in the C compiler market any
more. For any given platform, the choice is typically between the
vendor's compiler and GCC, and that decision is almost never made based
on which supports C99 better. When there's little competition, there's
little incentive.
Another problem is that the resources that used to be dedicated to
supporting C are now typically supporting both C and C++, so there are
fewer resources available.
-Larry Jones
Oh, now don't YOU start on me. -- Calvin
Dan Pop wrote: Chris Hills writes:
I think it is the complexity coupled with
the lack of requirement for a C99 compiler that is the problem.
If there was an industrial/commercial requirement
that we all use C99 compilers they would all be C99 compilers.
You can safely drop the complexity bit from the picture:
two tiny businesses, Comeau and Dinkumware
have produced an implementation claiming C99 conformance since quite a while.
The bigger vendors could have done it a lot faster.
The real reasons are:
1. Lack of interest from the C community at large.
The development of C99 was mostly politically driven
and little attention was paid to what the C programmers actually needed/wanted.
GNU C extensions of proven value have been completely ignored,
but we've got plenty of Fortran features
with little relevance to the main C problem domains.
2. C99 features conflicting with existing C89 extensions of many implementors.
The implementors are reluctant to break their users' code
by implementing the C99 semantics of the same feature.
See an older discussion
about why GNU C people don't want to change their compiler according to C99.
gcc got quite close to C99 conformance
when version 3.0 was released (over three years ago),
but didn't make any significant progress ever since...
As a result, most implementations have C99 extensions,
but this doesn't help people writing portable code,
as there is no commonly supported subset of C99
(with the possible exception of // comments).
If there was "no commonly supported subset of C99",
I would think that I would be having more trouble porting C99 code
but I'm *not* experiencing any such trouble.
Evidently, I haven't tried to use any of the the features
that aren't implemented yet because they aren't useful to me --
actually, I don't understand all of the new features
and I don't know whether they would be useful to me or not.
It appears to me that there actually *is* a common subset of C99
among the compilers (GNU, Intel, SGI, etc.) that I have used.
Is it really taking much longer to implement C99
than it took to implement C89?
How much longer do you think that it will take
before implementations approach "full" compliance with C99?
Perhaps we need to shelve the C99 standard
and simply describe and document the de facto standard so that
programmers can use the C99 features that are already implemented.
In comp.std.c Dan Pop <Da*****@cern.ch> wrote:
1. Lack of interest from the C community at large. The development of
C99 was mostly politically driven and little attention was paid to
what the C programmers actually needed/wanted.
That is absolutely untrue.
GNU C extensions of
proven value have been completely ignored, but we've got plenty of
Fortran features with little relevance to the main C problem domains.
It is true that much of C99 was targeted at the numerical community, but
that's because they're the ones that cried loudest and did the work to
create proposals and get them adopted. Numerical programming may be a
boutique market, but it's an important one. And the main reason that C
wasn't used much by that market is because it didn't support them very
well.
2. C99 features conflicting with existing C89 extensions of many
implementors.
Not many implementors, primarily just GCC. That is unfortunate, but not
unsurprising given the historical tendancy of GCC to adopt extensions
with little or no thought given to rigorous definition or to portability
outside the mainstream architectures. Not to mention the historical
disinterest in standards by the GCC developers and user community who
couldn't be bothered to participate in the standardization effort and
even actively opposed it at one time. I hasten to note, however, that
that attitude has now changed significantly, it's just unfortunate that
it didn't happen sooner.
-Larry Jones
Can I take an ax to school tomorrow for ... um ... show and tell? -- Calvin
In article <1H******************@newssvr27.news.prodigy.com >, "Mabden" <mabden@sbc_global.net> writes: "Michael Wojcik" <mw*****@newsguy.com> wrote in message
news:ch*********@news2.newsguy.com...
In this matter you appear to be in the minority of posters to c.l.c
who have expressed an opinion; that being the case, I imagine you'll
have to come up with a stronger argument than "I don't like it".
People are able to decide who to listen to,
Yes. However, they have historically not been able to make that
decision well, absent any information about the person speaking....
Usenet is by its nature an antagonistic forum; it does not lend
itself to the gradual building of consensus....
Public response is the only direct mechanism available
for vetting the ideas presented in unmoderated newsgroups. Asking
people to refrain from making such responses is tantamount to asking
them to reduce the information content of the group.
Understood, but I feel like I'm in a Monty Python skit at this point.
"An argument is a connected series of statements intended to establish a
proposition. It's not just saying, 'No it isn't.'"
I have seen several responses to your previous posts, including my
own, which contained significant information and were not simply
contradiction. In fact, I don't see anywhere in my post where I
contradicted anything you wrote.
When some one makes a remark on the usenet it may be correct, it may be
false, it may be somewhere in between. You are free to correct the poster,
or ignore the error. But to just post to say, "This guy is a shithead" isn't
helpful.
The "troll alert" messages to which you're objecting alert readers
to an established history of questionable posting. That's not the
simple attack you make it out to be.
Just killfile him and YOU won't have to hear what he has to say, and the
rest of us can go on listening to whomever we choose.
I don't know why you think I don't want to read ERT's posts, or why
you believe my refraining from doing so has any effect on whom you
read.
Now, unfortunately for me, I don't wish to killfile the posters doing it
like CBF, yourself,
I'm sorry, but could you cite these anti-ERT posts of mine? I don't
recall writing them, and Google doesn't appear to have any record of
them.
Someone uncharitable might feel that you are tarring all your
opponents with the same brush. Or that you respond to posts without
reading them carefully first, or that you don't put sufficient
thought into your posts, or that you suffer from delusions.
Fortunately, I am a model of charity.[1]
In fact, I have never even specifically advocated posting such "troll
alerts", as far as I recall. The post to which you responded makes
an argument (two arguments, actually) against advocating surpressing
them, but that is hardly the same thing.
In any case, I am merely stating again,
for anyone still reading, that I don't find any recent posts by ERT to
display any trolling or inappropriate language, but I have seen such
behaviour in those following along behind him issuing harassing missives
behind his back EVERY TIME. That is a troll.
How are public posts "behind his back"?
Also, that's a rather idiosyncratic definition of trolling you're
applying there. If you were to claim, say, that they were ad
hominem arguments, you might be on stronger ground. (They are, of
course, ad hominem arguments. But while argumentum ad hominem is a
*logical* fallacy, it does not follow that all ad hominem arguments
have no value for intellectual work.)
Killfile me if you want, but please killfile ERT first so I don't have to
read your flames about him anymore.
You haven't had to read them in the past. In fact, you haven't been
able to, since they don't exist. Any "flames" I composed regarding
ERT concerned his arguments, and were directed right at him. (And
there don't appear to have been many of those, either.)
1. Note that I didn't claim to be a *working* model. Nor do I mention
at what scale.
--
Michael Wojcik mi************@microfocus.com
Pogo: The dogs *scarcely* ever catches the rabbit.
Bun: "Scarcely" got a very unpleasant ring of frequency to it.
-- Walt Kelly
"James Kuyper" <ku****@wizard.net> wrote in message
news:8b**************************@posting.google.c om... "Mabden" <mabden@sbc_global.net> wrote in message
news:<_x******************@newssvr27.news.prodigy. com>... "Dan Pop" <Da*****@cern.ch> wrote in message
news:ch**********@sunnews.cern.ch...
... needs. This doesn't make them C99 compilers and this is far from
justifying the usage of C99 features in *portable* C code (which
happens to be the main focus of this newsgroup).
OK, so the "main focus" of this newsgroup is a compiler that doesn't
exist?
No, he said it was "portable code", not "a compiler".
<putting on the flame-retardant underwear>
OK, I see, the "code" is portable, but there are no compilers on any of the
"machines" to compile it yet. Right? It is "in theory" portable code, that
will "one day" be compilable everywhere, but not quite yet. And this is the
"main focus" of this newsgroup. Am I getting this right yet...?
....and ERT is a troll for saying he has one?
<leaving underwear on, just in case>
--
Mabden
"Michael Wojcik" <mw*****@newsguy.com> wrote in message
news:ch*********@news4.newsguy.com...
In article <1H******************@newssvr27.news.prodigy.com >, "Mabden"
<mabden@sbc_global.net> writes: "Michael Wojcik" <mw*****@newsguy.com> wrote in message
news:ch*********@news2.newsguy.com...
In this matter you appear to be in the minority of posters to c.l.c
who have expressed an opinion; that being the case, I imagine you'll
have to come up with a stronger argument than "I don't like it".
> People are able to decide who to listen to,
Yes. However, they have historically not been able to make that
decision well, absent any information about the person speaking....
Usenet is by its nature an antagonistic forum; it does not lend
itself to the gradual building of consensus....
Public response is the only direct mechanism available
for vetting the ideas presented in unmoderated newsgroups. Asking
people to refrain from making such responses is tantamount to asking
them to reduce the information content of the group.
Understood, but I feel like I'm in a Monty Python skit at this point.
"An argument is a connected series of statements intended to establish a
proposition. It's not just saying, 'No it isn't.'"
I have seen several responses to your previous posts, including my
own, which contained significant information and were not simply
contradiction. In fact, I don't see anywhere in my post where I
contradicted anything you wrote.
Which makes this reply so confusing. Why are you going back and making a new
thread on this old topic. I responded to your last thread, but now we're
getting circular here.
When some one makes a remark on the usenet it may be correct, it may be
false, it may be somewhere in between. You are free to correct the
poster, or ignore the error. But to just post to say, "This guy is a shithead"
isn't helpful.
The "troll alert" messages to which you're objecting alert readers
to an established history of questionable posting. That's not the
simple attack you make it out to be.
But what I'm opbjecting to is the AUTOMATIC "troll alert". Every statement
was being followed by a no-content misive (sounds like missile, get it)
"warning". Now, I haven't seen one lately, so I thank those who are laying
off but it was getting old. And tedious. And slightly insulting to readers;
who are "you" (not you personally, but the troll alert posters) to tell me
who's a troll. Will you tell me which books and magazines to read next?!
Just killfile him and YOU won't have to hear what he has to say, and the
rest of us can go on listening to whomever we choose.
I don't know why you think I don't want to read ERT's posts, or why
you believe my refraining from doing so has any effect on whom you
read.
Huh? I just don't want the warnings. I like reading from the posters making
the warnings, I mean when they post content.
Now, unfortunately for me, I don't wish to killfile the posters doing it
like CBF, yourself,
I'm sorry, but could you cite these anti-ERT posts of mine? I don't
recall writing them, and Google doesn't appear to have any record of
them.
Of course you are right. I apologize for lumping you in with "them". You
actually respond quite respectfully to his posts. Well, mostly. I'm not sure
why we are even talking about this, since you seem to be one of the people
who _doesn't_ do what I'm talking about.
<snip>
Also, that's a rather idiosyncratic definition of trolling you're
applying there. If you were to claim, say, that they were ad
hominem arguments, you might be on stronger ground. (They are, of
course, ad hominem arguments. But while argumentum ad hominem is a
*logical* fallacy, it does not follow that all ad hominem arguments
have no value for intellectual work.)
Well, I didn't have the correct term, cos I tain't that smart. But that
sounds like what I meant! Killfile me if you want, but please killfile ERT first so I don't have
to read your flames about him anymore.
You haven't had to read them in the past. In fact, you haven't been
able to, since they don't exist. Any "flames" I composed regarding
ERT concerned his arguments, and were directed right at him. (And
there don't appear to have been many of those, either.)
Again, I didn't mean you. Sorry for the confusion.
--
Mabden
On Thu, 02 Sep 2004 22:40:19 GMT, "Mabden" <mabden@sbc_global.net>
wrote:
An ever more tedious rambling about our bad treatment of poor ERT, who
is at a loss to defend himself.
Please mark this thread Off Topic.
--
Al Balmer
Balmer Consulting re************************@att.net
[snips]
On Mon, 30 Aug 2004 22:39:34 -0500, Jack Klein wrote: #include <stdlib.h>
int main(int argc, char **argv)
{
int foo[atoi(argv[1])];
}
that will simply invoke undefined behavior if the user enters, say,
'./a.out 1000000' and there's not enough memory to satisfy such a
request?
That does seem like a weird "feature" to add to C99, then, if it
can just fail randomly with no chance of recovery! :(
[xpost to c.s.c added]
Why so strange? This program can fail:
#include <stdio.h>
int main(void)
{
int foo [1000000];
foo [999999] = 42;
printf("%d\n", 42);
}
Granted. However, it seems to me that VLAs are sort of a "lazy man's
malloc", but without the error handling ability.
If we can't check to see if, say, there's 10,000 ints worth of available
memory for allocation, we can't assume we can allocate an array of 10,000
ints - so we can't use a VLA int array of size 10,000. But we can't,
AFAIAA, either check for available memory, or check the results of the
allocation.
Net result, it sems, is that we should stick to malloc: if there isn't
enough room to allocate our 10,000 int array, we'll just get a NULL back
and we can react accordingly.
Kelsey Bjarnason wrote: Granted. However, it seems to me that VLAs are sort of a "lazy man's
malloc", but without the error handling ability.
Used with caution they're no worse than any other auto
variable. Until C gets exceptions there isn't any good
solution to the general stack overrun problem (and even
then, the exception handler might overrun the stack too).
"Alan Balmer" <al******@att.net> wrote in message
news:cg********************************@4ax.com... On Thu, 02 Sep 2004 22:40:19 GMT, "Mabden" <mabden@sbc_global.net>
wrote:
An ever more tedious rambling about our bad treatment of poor ERT, who
is at a loss to defend himself.
Please mark this thread Off Topic.
Don't worry I'm pretty much done now. Even I got bored reading my posts! ;-)
I started as just a simple request, but kinda blew up around me.
'Nuff said.
--
Mabden
Mabden wrote: "Alan Balmer" <al******@att.net> wrote in message "Mabden" <mabden@sbc_global.net> wrote:
An ever more tedious rambling about our bad treatment of poor
ERT, who is at a loss to defend himself.
Please mark this thread Off Topic.
Don't worry I'm pretty much done now. Even I got bored reading my
posts! ;-) I started as just a simple request, but kinda blew up
around me. 'Nuff said.
Meanwhile Trollsdale has struck again in another thread.
--
"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
In <h2************@jones.homeip.net> la************@ugs.com writes: In comp.std.c Dan Pop <Da*****@cern.ch> wrote:
1. Lack of interest from the C community at large. The development of
C99 was mostly politically driven and little attention was paid to
what the C programmers actually needed/wanted.
That is absolutely untrue.
Then, please explain the lack of interest in C99 among the C programming
community at large. GNU C extensions of
proven value have been completely ignored, but we've got plenty of
Fortran features with little relevance to the main C problem domains.
It is true that much of C99 was targeted at the numerical community, but
that's because they're the ones that cried loudest and did the work to
create proposals and get them adopted. Numerical programming may be a
boutique market, but it's an important one. And the main reason that C
wasn't used much by that market is because it didn't support them very
well.
And it was too late to change this state of facts by 1999. Those people
didn't wait for C to provide what they were missing, they simply adopted
either F90 or C++ (or simply contined to use traditional FORTRAN with the
common set of extensions) and kept doing their work.
If the commitee keeps its collective head in the sand instead of
admitting that C99 was a failure and trying to lucidly analyse the reasons
of this failure, chances are that C89 plus a set of extensions becoming a
de facto standard will be the future definition of C as far as the C
programming community at large is concerned and future ISO C standards
will be exercises in futility. 2. C99 features conflicting with existing C89 extensions of many
implementors.
Not many implementors, primarily just GCC.
And GNU C is the very last language you'd want a new C standard to
conflict with. Without these conflicts, gcc would have been a conforming
C99 translator by the time gcc 3.0 was released or shortly afterwards and
this would have created the motivation for commercial implementors to
support C99, too. End result: success instead of failure.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <pa****************************@xxnospamyy.lightsp eed.bc.ca> Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> writes: Granted. However, it seems to me that VLAs are sort of a "lazy man's
malloc", but without the error handling ability.
OTOH, VLAs are invaluable as function parameters, where there are no
allocation failure issues.
Imagine that you want to write a 2-dim matrix multiplication function,
without knowing the sizes of the matrices. In C89, you have to treat
the matrices as 1-dim arrays and do all the index arithmetic yourself,
impairing the code readability. Or implement the matrices using dope
vectors, which is likely to adversely affect the code performance.
Using VLAs, the code is as straightforward as its Fortran equivalent.
Throw in "restrict" and the performance is likely to match that of the
Fortran code, too.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In article <ch**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote: And GNU C is the very last language you'd want a new C standard to
conflict with. Without these conflicts, gcc would have been a conforming
C99 translator by the time gcc 3.0 was released or shortly afterwards and
this would have created the motivation for commercial implementors to
support C99, too. End result: success instead of failure.
As I stated in my previous posting on the subject, this is not an
accurate representation of the reasons behind the status of C
standards implementation in GCC. Such conflicts are not an issue; we
are perfectly capable of conditioning choices of conflicting behavior
on command-line options, just as C compilers need to contain
appropriate conditionals for differences between C90 and C99. Examine
what C99 features (and other conformance improvements) have been
implemented when and by whom in GCC over the past four years. Outside
the preprocessor, where the work has been done by other people, you
should see the strong correlation I indicated in my previous message
with when I have been able to work on implementing them, and the lack
of any funding for C99 or conformance implementation. Only a few C99
features have been implemented by other people, who may have had
funding to do so.
You may speculate on the reasons for lack of funded implementation
effort. The most obvious would be that lack of C99 implementations
means lack of users with C99 code, so lack of demand for such
implementations.
GCC does not have a conforming C90 implementation either. I have been
working on this, but whether it is completed comes down to much the
same issues. (Plus the point that guesswork is rather involved in
ascertaining whether it is done or not, given the presumed expense of
third-party conformance testsuites and the apparent restrictions on
any developers who might have access to such disclosing their results
to any who might be working on conformance.)
--
Joseph S. Myers js***@gcc.gnu.org
Dan Pop wrote:
.... snip ...
And GNU C is the very last language you'd want a new C standard
to conflict with. Without these conflicts, gcc would have been a
conforming C99 translator by the time gcc 3.0 was released or
shortly afterwards and this would have created the motivation for
commercial implementors to support C99, too. End result: success
instead of failure.
This may be the wrong venue in which to ask, but how many
programmers really use the GNU extensions? I know I have used
only one in one particular package in the past two years, and that
was effectively for a system component. In that case I used
variadic macros, and picked the GNU variety because it would be
more widely available.
--
"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
CBFalconer <cb********@yahoo.com> writes: Dan Pop wrote:
... snip ...
And GNU C is the very last language you'd want a new C standard
to conflict with. Without these conflicts, gcc would have been a
conforming C99 translator by the time gcc 3.0 was released or
shortly afterwards and this would have created the motivation for
commercial implementors to support C99, too. End result: success
instead of failure.
This may be the wrong venue in which to ask, but how many
programmers really use the GNU extensions? I know I have used
only one in one particular package in the past two years, and that
was effectively for a system component. In that case I used
variadic macros, and picked the GNU variety because it would be
more widely available.
I rarely do, though I use gcc all the time, because the C code I work
on has be reasonably portable to other compilers.
I think the Linux kernel depends on gcc extensions.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Dan Pop wrote: Then, please explain the lack of interest in C99
among the C programming community at large.
Which begs the question,
"Is there a lack of interest in C99
among the C programming community at large?
What evidence do you have to support this assertion?
Joseph Myers wrote: Dan Pop wrote:
And GNU C is the very last language you'd want a new C standard to
conflict with. Without these conflicts, gcc would have been a conforming
C99 translator by the time gcc 3.0 was released or shortly afterwards and
this would have created the motivation for commercial implementors to
support C99, too. End result: success instead of failure.
As I stated in my previous posting on the subject,
this is not an accurate representation of the reasons
behind the status of C standards implementation in GCC.
Such conflicts are not an issue; we are perfectly capable
of conditioning choices of conflicting behavior
on command-line options, just as C compilers need to contain
appropriate conditionals for differences between C90 and C99.
Examine what C99 features (and other conformance improvements)
have been implemented when and by whom in GCC over the past four years.
Outside the preprocessor, where the work has been done by other people,
you should see the strong correlation I indicated in my previous message
with when I have been able to work on implementing them,
and the lack of any funding for C99 or conformance implementation.
Only a few C99 features have been implemented by other people,
who may have had funding to do so.
You may speculate on the reasons for lack
of funded implementation effort. The most obvious would be that
lack of C99 implementations means lack of users with C99 code,
so lack of demand for such implementations.
GCC does not have a conforming C90 implementation either.
Note that this is a direct contradiction of Robert Gamble's assertion:
'The documentation implies full conformance to c90:
"GCC supports three versions of the C standard, although
support for the most recent version is not yet complete."'
I have been working on this,
but whether it is completed comes down to much the same issues.
(Plus the point that guesswork is rather involved
in ascertaining whether it is done or not,
given the presumed expense of third-party conformance testsuites
and the apparent restrictions on any developers
who might have access to such disclosing their results
to any who might be working on conformance.)
Actually, Greg Comeau does *not* claim that his compilers comply
with ANSI/ISO standards but that other [authorities] make that claim.
How would you characterize the "pace" of the GNU C 99 implementation.
Is it proceeding more slowly
than the GNU C 89 implementation ten years ago?
Suppose that you got adequate funding tomorrow.
How long would it take to produce an ANSI/ISO compliant C 99 compiler?
In article <ch**********@nntp1.jpl.nasa.gov>, E. Robert Tisdale
<E.**************@jpl.nasa.gov> writes Chris Hills wrote:
IE. Robert Tisdale writes
Malcolm wrote:
The difference is that C99 was designed by a standards body.
Your indictment of ANSI
It was not an indictment of ANSI....
ANSI is only one of a large number of National Bodies
that make up the ISO WG14 who produce the C standard.
Malcolm mentions only ANSI.
What fraction of the blame belongs to these other "National Bodies"?
And who are they?
Most countries of the world. ANSI gets one vote like all the rest. The
C standard is an ISO standard. seems to imply that
it is taking a lot longer for C compiler developers to implement
the C99 standard than it took to implement the C89 standard
and that the blame for the delay belongs [mostly] with ANSI
and *not* with the C compiler developers.
Well, ISO [has] produced the standard
[that] the compiler writers [must] work to.
The simpler the standard the easier it is to do.
The compiler writers are, on the whole, commercial. If the world really
demanded a C99 compiler, they would be more likely to do them faster.
So the "world" is to blame for the delay in full compliance?
It's a bit of everything...
The ISO committee who produced a standard that is difficult to implement
The SW Industry for not requiring ISO-C compilers. I think it is the complexity coupled with
the lack of requirement for a C99 compiler that is the problem.
If there was an industrial/commercial requirement
that we all use C99 compilers, they would all be C99 compilers.
So C99 is the standard that nobody wanted?
Not at all. It is a standard that not enough people want or have to use.
I note that most of the worlds major embedded compiler writers have
managed to implement MISRA-C compliance in their libraries over the same
period... 1999 to now. And that was from a standing start (there was no
MISRA-C before 1998).
SO it is down to commercial will as much as anything else.
If the industry required ISO-C compilers (as the ADA community require
certified compilers) then we would have them. Though I am informed by
several people who know that the C99 has some serious flaws in it.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <la************@jones.homeip.net>, la************@ugs.com
writes In comp.std.c James Kuyper <ku****@saicmodis.com> wrote:
Yes. By "the world", what is meant is people who purchase compilers. If
those people really demanded C99 compliance, and refused to purchase
non-compliant compilers, the compiler vendors would rush to accommodate
them. Since there's been no strong demand for C99 compliance, it has
come far more slowly.
There's also essentially no competition in the C compiler market any
more. For any given platform, the choice is typically between the
vendor's compiler and GCC,
That is not true. There is a lot of competition. the problem is that
ISO-C compliance is not a high requirement. This is a pity.
However strict conformance to ISO-C would be difficult if not impossible
for a lot of C compilers.
and that decision is almost never made based
on which supports C99 better.
That is true. There is no requirement, or rarely any, for an ISO-C
complaint compiler. I think in time this may happen. Unfortunately I
think it will be down to the insurance companies trying to minimise risk
rather than engineering requirements.
When there's little competition, there's
little incentive.
Another problem is that the resources that used to be dedicated to
supporting C are now typically supporting both C and C++, so there are
fewer resources available.
That is not the case.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <ch**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch>
writes In <uV**************@phaedsys.demon.co.uk> Chris Hills <ch***@phaedsys.org>
writes:
I think it is the complexity coupled with the lack of requirement for a
C99 compiler that is the problem. If there was an industrial/commercial
requirement that we all use C99 compilers they would all be C99
compilers.
You can safely drop the complexity bit from the picture:
I am not so sure about that. I know some people with real concerns about
some parts of the C99 model. (their job is in validation)
two tiny
businesses, Comeau and Dinkumware have produced an implementation
claiming C99 conformance since quite a while. The bigger vendors could
have done it a lot faster.
Also the Tasking Tricore compiler.
Has anyone actually validated these two/three compilers?
The real reasons are:
1. Lack of interest from the C community at large. The development of
C99 was mostly politically driven and little attention was paid to
what the C programmers actually needed/wanted. GNU C extensions of
proven value have been completely ignored, but we've got plenty of
Fortran features with little relevance to the main C problem domains.
2. C99 features conflicting with existing C89 extensions of many
implementors. The implementors are reluctant to break their users'
code by implementing the C99 semantics of the same feature. See an
older discussion about why GNU C people don't want to change their
compiler according to C99. gcc got quite close to C99 conformance
when version 3.0 was released (over three years ago), but didn't make
any significant progress ever since...
As a result, most implementations have C99 extensions, but this doesn't
help people writing portable code, as there is no commonly supported
subset of C99 (with the possible exception of // comments).
Not even the // are supported in the same way. :-(
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <41***************@yahoo.com>, CBFalconer
<cb********@yahoo.com> writes Joseph Myers wrote:
... snip ...
When C99 features or other conformance improvements have been
added to GCC over the last four years has been largely determined
by when I have been able to work on implementing them and by the
lack of any funding for C99 or conformance implementation.
... snip ...
Excellent. One thing that annoys me (please correct if I am
wrong) is that I understand gcc requires the gnu extensions to
compile itself. It would be a great boost to portability if it
required nothing more than C89 compliance.
or even C90
:-)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <h2************@jones.homeip.net>, la************@ugs.com
writes In comp.std.c Dan Pop <Da*****@cern.ch> wrote:
1. Lack of interest from the C community at large. The development of
C99 was mostly politically driven and little attention was paid to
what the C programmers actually needed/wanted.
That is absolutely untrue.
So why aren't C programmers pushing for C99? It C99 was important to
them surely the compiler writers would be producing?
GNU C extensions of
proven value have been completely ignored, but we've got plenty of
Fortran features with little relevance to the main C problem domains.
It is true that much of C99 was targeted at the numerical community, but
that's because they're the ones that cried loudest and did the work to
create proposals and get them adopted. Numerical programming may be a
boutique market, but it's an important one. And the main reason that C
wasn't used much by that market is because it didn't support them very
well.
I am told there are a lot of problems with the maths in C99. this was by
a mathematician who's arguments was way beyond my ken...
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <ch**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch>
writes In <h2************@jones.homeip.net> la************@ugs.com writes:
In comp.std.c Dan Pop <Da*****@cern.ch> wrote:
1. Lack of interest from the C community at large. The development of
C99 was mostly politically driven and little attention was paid to
what the C programmers actually needed/wanted.
That is absolutely untrue.
Then, please explain the lack of interest in C99 among the C programming
community at large.
This is one of the major problems. There is no requirement to have an
ISO-C compiler. For some reason, unlike the ADA crowd the C community
seems to be a lot less interested in standards and "SW Engineering" as
opposed to "programming"
If the commitee keeps its collective head in the sand instead of
admitting that C99 was a failure and trying to lucidly analyse the reasons
of this failure, chances are that C89 plus a set of extensions becoming a
de facto standard will be the future definition of C as far as the C
programming community at large is concerned and future ISO C standards
will be exercises in futility.
I have heard several C standards people express exactly that thought.
However they are generally not seen in a good light in the main ISO-C
body so I have been told.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <ch**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch>
writes If the commitee keeps its collective head in the sand instead of
admitting that C99 was a failure and trying to lucidly analyse the reasons
of this failure,
chances are that C89 plus a set of extensions becoming a
de facto standard will be the future definition of C as far as the C
programming community at large is concerned and future ISO C standards
will be exercises in futility.
I know of a team that actually looked at doing that. However pressures
of business and time put a stop to it. A pity.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <ch**********@nntp1.jpl.nasa.gov>, E. Robert Tisdale
<E.**************@jpl.nasa.gov> writes Dan Pop wrote:
Then, please explain the lack of interest in C99
among the C programming community at large.
Which begs the question,
"Is there a lack of interest in C99
among the C programming community at large?
What evidence do you have to support this assertion?
That is easy... None of the compiler writers I know have been asked for
it. They get hundreds/thousands of requests for all sorts of things from
both users, other tool makers and the silicon makes. C99 is not a
requirement that gets raised.
I have talked with several on this matter specifically.
If any of them could see any commercial advantage in producing a C99
compile they would. It is for this reason that most of the worlds major
embedded compiler writers are making their compilers MISRA-C compliant
(MISRA-C was first launched in 1997) and they are eager to tp become
MISRA-C2 compliant even before the new version has been published. (on
the 13th October BTW)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <ch**********@nntp1.jpl.nasa.gov>,
E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote: GCC does not have a conforming C90 implementation either.
Note that this is a direct contradiction of Robert Gamble's assertion:
'The documentation implies full conformance to c90:
"GCC supports three versions of the C standard, although
support for the most recent version is not yet complete."'
I recommend reading the whole of the relevant section of the manual
<http://gcc.gnu.org/onlinedocs/gcc/Standards.html> rather than just an
isolated extract. In particular
For each language compiled by GCC for which there is a standard,
GCC attempts to follow one or more versions of that standard,
possibly with some exceptions, and possibly with some extensions.
and
GCC aims towards being usable as a conforming freestanding
implementation, or as the compiler for a conforming hosted
implementation.
- note the "attempts to follow" and "aims towards".
Support for C99 is not feature-complete (nor fully correct for some
features where there is approximate support for the standard).
Support for C90 is not fully correct, though the language features are
there and most users who do not read comp.std.c may not notice that
constant expression constraints don't work.
How would you characterize the "pace" of the GNU C 99 implementation.
Is it proceeding more slowly
than the GNU C 89 implementation ten years ago?
I do not know the pace of C89 implementation (when GCC development was
done on private mailing lists and with no bug tracking database),
though it evidently finished without getting all the fine details
right.
Suppose that you got adequate funding tomorrow.
How long would it take to produce an ANSI/ISO compliant C 99 compiler?
The C99 implementation could be completed in a few months. (That is
for targets with sane floating-point hardware; not 387 floating point
on x86 which makes it hard to do computations in the range and
precision of float / double or round those done in long double to the
range and precision of float / double without storing to memory.)
--
Joseph S. Myers js***@gcc.gnu.org
CBFalconer <cb********@yahoo.com> writes: This may be the wrong venue in which to ask, but how many
programmers really use the GNU extensions?
In portable software, I use the GNU extensions that don't hurt if
you don't have them. That's mainly the __attribute__ feature,
which you can conditionalize on __GNUC__. (Although testing
__GNUC__ may be undefined behavior, it would be foolish to claim
to be GNU C without implementing its extensions.)
Low-level system software often has to assume some compiler
anyway because e.g. it needs inline assembly. I'm more liberal
in my use of GNU extensions in such cases because I can't avoid
them anyway.
--
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield
Chris Hills <ch***@phaedsys.org> writes:
[...] This is one of the major problems. There is no requirement to have an
ISO-C compiler. For some reason, unlike the ADA crowd the C community
seems to be a lot less interested in standards and "SW Engineering" as
opposed to "programming"
A small off-topic quibble: It's Ada, not ADA. (The name isn't an
acronym.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Dan Pop wrote: Then, please explain the lack of interest in C99 among the C programming
community at large.
How do you know there is a "lack of interest"? Have you taken
a scientifically valid poll?
Anyway, until C99 compliance is sufficiently widely available,
it is unlikely to be a project requirement. That alone would
be sufficient to explain any apparent "lack of interest". This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Tao Wang |
last post by:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I saw cuj's conformance roundup, but the result is quite old. I think
many people like me want to know newer c++ standard conformance test...
|
by: Andrew |
last post by:
I use conditional compiler constants, set through the VBA IDE in
Tools, <projectname> Properties, that I refer to throughout my code to
control which code is used during development, and which...
|
by: J |
last post by:
I use Access 97 and Windows XP (Sp2 if that matters)
I mostly program for myself, but am now writing an
application for my wife's club and need to include
a help file with the database
I am...
|
by: Sean Wolfe |
last post by:
I have a request for the c# compiler one that is an obvious oversight in
my opinion. I'm not sure if this is already being implemented in
Whidebey, bu i would hope to find it in there, or in the...
|
by: Robert |
last post by:
Every time I navigate to any .aspx file on my computer, I get the error below. According to MSDN this indicates that my CLR is corrupt, but I've re-installed the .NET framework with no help. Also...
| | |
by: Steve |
last post by:
I have to develop several large and complex C++ hardware test programs that
should work under DOS, most likely with 32-bit DOS extender. Development
workstation OS would be Microsoft XP. Quite some...
|
by: mudge |
last post by:
Hi,
I'm getting some very strange problems with some C# code. We're running
an ASP.NET application on a local server in a DMZ. If I access it using
the internal address, the application works...
|
by: Dave |
last post by:
I'm having a hard time tying to build gcc 4.3.1 on Solaris using the GNU
compilers. I then decided to try to use Sun's compiler. The Sun Studio
12 compiler reports the following code, which is in...
|
by: dissectcode |
last post by:
In my code, I have bit fields in structures to access hw registers. I tested my compiler to see how it reads/writes to the registers and noticed that the compiler is trying to access the registers by...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
