Why the C committee doesn't provide an implementation when the standard is published?

[lovecreatesbeauty]

Why the C standard committee doesn't provide a standard implementation
including the C compiler and library when the language standard
document is published?

C works on the abstract model of low level machine. C stands for
portability and platform and machine independent. If the C compiler and
C standard library are written in C itself, is it possible that one
"standard" C compiler plus library is enough? The standard
implementation is published by the international standard committee. Is
it to hurried for the committee to do it? Does the committee take no
responsibility for publishing a standard implementation when release
the paper language document?

The standard implementation will never stop various non-standard
implementations from being produced by individual person or
organization. If all the programmers can have the standard
implementation as soon as the language standard is released, then all
programs can be written following the standard freely and strictly.

 

[Ian Collins]

Why the C standard committee doesn't provide a standard implementation
including the C compiler and library when the language standard
document is published?

Because it's not their job?

C works on the abstract model of low level machine. C stands for
portability and platform and machine independent. If the C compiler and
C standard library are written in C itself, is it possible that one
"standard" C compiler plus library is enough? The standard
implementation is published by the international standard committee. Is
it to hurried for the committee to do it? Does the committee take no
responsibility for publishing a standard implementation when release
the paper language document?

Some standard library functions can't be implemented in C, or at least
can't be optimally implemented in C.

It might be fun to define the standard library as a set of unit tests.

 

[Gordon Burditt]

Why the C standard committee doesn't provide a standard implementation

including the C compiler and library when the language standard
document is published?

To run under what, the "Standard OS" on the "Standard Hardware"?
It isn't the job of a standards committee to produce an implementation.

C works on the abstract model of low level machine. C stands for
portability and platform and machine independent.

But an *implementation* is not going to be platform and machine
independent.

If the C compiler and
C standard library are written in C itself, is it possible that one
"standard" C compiler plus library is enough?

No, if it's expected to produce native machine code.

The standard
implementation is published by the international standard committee. Is
it to hurried for the committee to do it? Does the committee take no
responsibility for publishing a standard implementation when release
the paper language document?

No. Do the people who write building codes build buildings?

The standard implementation will never stop various non-standard
implementations from being produced by individual person or
organization. If all the programmers can have the standard
implementation as soon as the language standard is released, then all
programs can be written following the standard freely and strictly.

One of the potential problems of a "standard implementation" would
be that an extension (or incomplete error checking) in the "standard
implementation" would tend to become a de facto "standard extension"
when that may not have been intended by the standards committee.
The standard, not a "standard implementation" defines the language.

Gordon L. Burditt

 

[lovecreatesbeauty]

No. Do the people who write building codes build buildings?

It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler. Is it / standard not important? If
not, why the standard committee is very important and people need it?

 

[Richard Heathfield]

lovecreatesbeauty said:

It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler.

C99, yes. Please note, however, that C89 was a very different matter.
Vendors were rushing to conform to it, and most had conforming compilers
even before the ink was dry, because they'd been following the
standardisation process very closely. C89 mattered - and still matters.

Is it / standard not important?

C89 is vital. But C99? No, not really. Otherwise, we'd have more conforming
implementations by now.

If
not, why the standard committee is very important and people need it?

That's an excellent question. Perhaps someone from the committee would like
to answer it.

 

[Keith Thompson]

lovecreatesbeauty said: [...]

Is it / standard not important?

C89 is vital. But C99? No, not really. Otherwise, we'd have more conforming
implementations by now.

C89 (or C90) caught on as quickly as it did because there was a great
demand for a standard. When C99 was issued, there was already a
standard that worked well, so there was less demand for a new one.
But there are a *few* implementations that conform to C99, and more
that implement parts of C99.

If nothing else, the C99 standard provides a direction for development
beyond C90. For example, a C compiler vendor wants to implement
complex numbers will almost certainly do so using the syntax defined
by the C99 standard, rather than inventing something else.

 

[Chris Hills]

lovecreatesbeauty said:


C99, yes. Please note, however, that C89 was a very different matter.
Vendors were rushing to conform to it, and most had conforming compilers
even before the ink was dry, because they'd been following the
standardisation process very closely. C89 mattered - and still matters.

Actually ISO C90+A1 and the TC's..ie C95/6 This is where most compilers
are. Generally they have taken a few items from C99 but not many.

C89 is vital. But C99? No, not really. Otherwise, we'd have more conforming
implementations by now.

I agree.

That's an excellent question. Perhaps someone from the committee would like
to answer it.

AFAIK C99 was a "committee designed animal". Ie the Camel is a horse
designed by a committee

Several high profile committee members have said they wished certain
areas had not been included and that C99 has "lost it's way". The
evidence is that the main compiler vendors have not implemented it.

You have the problem that on the desktop most(?) users use MS compilers.
MS have stopped doing C and do C++.

BTW There is no such language as C/C++. C++ was developed from C90 and
diverged one way whilst C went a different way 95 and C99. So C written
in a C++ compiler is not C.

Most(?) desktop users of C actually use a [MS]C++ compiler and MS has
taken this off on their own direction added to which there is a lot of
use of Java, C# etc and other languages. So there is a lot less interest
in the desktop community to chase the ISO C99 standard that there used
to be when the industry wanted a common specification for the language
and C++ had not arrived.

The embedded community, probably the largest C community there is, is
sticking with C90/5 and not following C99. Most of the embedded world
still use 8 and 16 bit MCU's and most of the embedded standards relate
to C90 anyway.

GNU follows it's own path, though is does have a C90 mode and I think
they are "working towards" C99, but slowly.

In short no one really needed the new features of C99. Some it is
claimed are broken anyway. The maths model for example.

The UK C panel has got a bad reputation over the last few years for
saying "NO!" to adding anything to C99 before fixing some of the major
problems in the standard. In fact there was a suggestion that we Should
go back to C95 and start again! However this has been ignored.

So in my view (and others on the panel but I will let them speak for
themselves) There is a LOT of DR (defect report) work to be done on C99
before we add anything new to C99.

However other panels want to add lots of new things. "Building on
quicksand" as one C panel member said to me. So in my view C99 will
continue to wander off into the wilderness.

ECMA is doing it's own thing with C++ and you are likely to find that
the ISO C++ also goes off into the wilderness in the next few years just
like ISO BASIC.

Somewhere along the line ISO C and C++ have lost their way and I am not
sure how to get them back.

 

[Chris Hills]

lovecreatesbeauty said: [...]

Is it / standard not important?

C89 is vital. But C99? No, not really. Otherwise, we'd have more conforming
implementations by now.

C89 (or C90) caught on as quickly as it did because there was a great
demand for a standard.
Yes

When C99 was issued, there was already a
standard that worked well, so there was less demand for a new one.

True. also there was NO demand by the majority for a lot of the features
that were added.

But there are a *few* implementations that conform to C99,

I think 50% (ie three of them) were for political reasons only.

and more
that implement parts of C99.

I think "everyone" has implemented a few bits of C99. Though they have
ignored a LOT more than they have implemented.

If nothing else, the C99 standard provides a direction for development
beyond C90.

Not really.

For example, a C compiler vendor wants to implement
complex numbers will almost certainly do so using the syntax defined
by the C99 standard, rather than inventing something else.

Maybe. Maybe not. There are some features of the C standard that are
broken anyway. No one is really going to implement these or use them as
a base.

Several ISO C panel members have called for going back to C95 and
starting again.

 

[Martin Ambuhl]

AFAIK C99 was a "committee designed animal". Ie the Camel is a horse
designed by a committee

Notice that the oft-quoted line about the horse designed by a committee
is a poor substitute for a real argument. In particular, notice that the
most successful translation of the Bible ever, the Authorized / King
James Version, is the quintessential committee-designed translation.

 

[jjf]

It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler.

Nonsense. There are many C compilers which are 100% compliant to the C
Standards from 1996 and earlier.

Is it / standard not important?

It is important.

 

[Chris Hills]

Notice that the oft-quoted line about the horse designed by a committee
is a poor substitute for a real argument.

Hence the

In particular, notice that the
most successful translation of the Bible ever, the Authorized / King
James Version, is the quintessential committee-designed translation.

That was political.... Besides it depends how you define "successful" in
this case. But that is very much OT.

 

[Chris Hills]

Nonsense. There are many C compilers which are 100% compliant to the C
Standards from 1996 and earlier.

They are Obsolete standards. The compilers are NOT C compliant as
defined by ISO. Ie ISO9899:1999 (any other version of ISO9899 is
OBSOLETE)

It is important.

Why?

 

[Richard Heathfield]

Chris Hills said:

They are Obsolete standards. The compilers are NOT C compliant as
defined by ISO.

But as far as the Real World is concerned, they /are/ conforming
implementations. For as long as the ISO C committee could carry the Real
World with it, the distinction between ISO's view and that of the Real
World was irrelevant. But because they can no longer do that, it has become
very relevant indeed.

Ie ISO9899:1999 (any other version of ISO9899 is OBSOLETE)

Only as far as ISO is concerned.

 

[Martin Ambuhl]

Hence the


That was political.... Besides it depends how you define "successful" in
this case. But that is very much OT.

To dominate the religious and literary life of English speakers from
1660, when the Geneva Bible, last printed in 1644 was suppressed by the
same regime that reintroduced such civilized touches as the censorship
and compulsory Sunday service attendance, until at least 1952, when the
RSV was introduced is more successful than anything that any of us can
claim, I assure you. You need an extremely perverse definition of
"successful" to find any translation of the Bible that was more successful.

 

[Jean-Marc Bourguet]

You need an extremely perverse definition of "successful" to find
any translation of the Bible that was more successful.

The Vulgate

Yours,

 

[Chris Hills]

To dominate the religious and literary life of English speakers from
1660, when the Geneva Bible, last printed in 1644 was suppressed by the
same regime that reintroduced such civilized touches as the censorship
and compulsory Sunday service attendance, until at least 1952, when the
RSV was introduced is more successful than anything that any of us can
claim, I assure you. You need an extremely perverse definition of
"successful" to find any translation of the Bible that was more successful.

It was successful in much the same way the Colombian drugs cartels are.
They spread their stuff far and wide.

 

[Chris Hills]

Chris Hills said:


But as far as the Real World is concerned, they /are/ conforming
implementations.

In which case as far as the real world is concerned any of the compilers
that people want to discuss here are also C compilers.... You can't have
it both ways.

For as long as the ISO C committee could carry the Real
World with it, the distinction between ISO's view and that of the Real
World was irrelevant.
Agreed.

But because they can no longer do that, it has become
very relevant indeed.

I agree.

Only as far as ISO is concerned.

AND BSI.... Took me a hell of a time to get them to make the C95 version
available again! They were very pleased when sales of C95 in the last
three years out striped the total sales of C99 at BSI

However BSI have now run out of their copies of C95 :-( the ISO version
is Obsolete and very expensive. (over 150USD) So I am working on getting
it published at a far lower rate. It is going to take a while but I am
working on it.

 

[Richard Heathfield]

Chris Hills said:

In which case as far as the real world is concerned any of the compilers
that people want to discuss here are also C compilers.... You can't have
it both ways.

Well, clc isn't *exactly* the real world. But to take your point more
seriously, my understanding of the consensus of regular contributors on clc
topicality is that K&R C is topical, as is any subsequent formal
standardisation by ISO. So, currently, K&R C, ISO C90, its subsequent
corrigenda and amendments, ISO C99, and /its/ subsequent corrigenda and
amendments, are all topical. And unless the consensus changes dramatically,
they will all remain so.

AND BSI.... Took me a hell of a time to get them to make the C95 version
available again! They were very pleased when sales of C95 in the last
three years out striped the total sales of C99 at BSI

And that in itself shows that C95 is far from obsolete. After all, you don't
buy a copy of the Standard unless you have correctness or portability
concerns - so if C95 is selling well, it shows that people consider it to
be an authority on correctness and portability.

 

[Chris Hills]

Chris Hills said:


Well, clc isn't *exactly* the real world.

exactly.

But to take your point more
seriously, my understanding of the consensus of

some of the

regular contributors on clc
topicality is that K&R C is topical, as is any subsequent formal
standardisation by ISO. So, currently, K&R C, ISO C90, its subsequent
corrigenda and amendments, ISO C99, and /its/ subsequent corrigenda and
amendments, are all topical. And unless the consensus changes dramatically,
they will all remain so.

the rest of us widen it to include all C compilers.

And that in itself shows that C95 is far from obsolete.

In the real world that is the case. In fact ISO C95/6 *IS* the
standard.

After all, you don't
buy a copy of the Standard unless you have correctness or portability
concerns - so if C95 is selling well, it shows that people consider it to
be an authority on correctness and portability.

Yes. It is also why MISRA-C is based on C90. MISRA has to work in
reality.

 

[Frank Silvermann]

Actually ISO C90+A1 and the TC's..ie C95/6 This is where most compilers
are. Generally they have taken a few items from C99 but not many.



I agree.


AFAIK C99 was a "committee designed animal". Ie the Camel is a horse
designed by a committee

Several high profile committee members have said they wished certain
areas had not been included and that C99 has "lost it's way". The
evidence is that the main compiler vendors have not implemented it.

You have the problem that on the desktop most(?) users use MS compilers.
MS have stopped doing C and do C++.

BTW There is no such language as C/C++. C++ was developed from C90 and
diverged one way whilst C went a different way 95 and C99. So C written
in a C++ compiler is not C.

I would have objected strenuously to this before this morning. Now I
don't quite know what to think about this garbage on my clipboard:
Compiling...
Text1.c
C:\MSDEV\Projects\tja15\Text1.c(14) : error C2143: syntax error : missing
';' before 'type'
C:\MSDEV\Projects\tja15\Text1.c(15) : error C2065: 'c' : undeclared
identifier
Error executing cl.exe.
Text1.obj - 2 error(s), 0 warning(s)
/* end output of cl.exe; begin source */
#include <stdio.h>

#define SIX 1+5
#define NINE 8+1

int main(void)
{
int a =SIX;
int b =NINE;
printf("In main SIX is %d while NINE is %d\n", a ,b);
/* int c = (1 + 5 * 8 + 1);*/
/* int c; */
int c;
c = 8;

/*printf("Is the culprit the grouping? %d\n", c); */
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}

/* end source */
The Germans are telling me that I can't have the declaration after the
printf, a feature demanded by C99. Furthermore, I found out that arctan
of a float is defined in math.h for this implementation although this
requirement didn't exist in '94 or so when I bought it. I don't know
what all that means, but I think it means something.

Most(?) desktop users of C actually use a [MS]C++ compiler and MS has
taken this off on their own direction added to which there is a lot of
use of Java, C# etc and other languages. So there is a lot less interest
in the desktop community to chase the ISO C99 standard that there used
to be when the industry wanted a common specification for the language
and C++ had not arrived.

The embedded community, probably the largest C community there is, is
sticking with C90/5 and not following C99. Most of the embedded world
still use 8 and 16 bit MCU's and most of the embedded standards relate
to C90 anyway.

GNU follows it's own path, though is does have a C90 mode and I think
they are "working towards" C99, but slowly.

In short no one really needed the new features of C99. Some it is
claimed are broken anyway. The maths model for example.

The UK C panel has got a bad reputation over the last few years for
saying "NO!" to adding anything to C99 before fixing some of the major
problems in the standard. In fact there was a suggestion that we Should
go back to C95 and start again! However this has been ignored.

So in my view (and others on the panel but I will let them speak for
themselves) There is a LOT of DR (defect report) work to be done on C99
before we add anything new to C99.

However other panels want to add lots of new things. "Building on
quicksand" as one C panel member said to me. So in my view C99 will
continue to wander off into the wilderness.

ECMA is doing it's own thing with C++ and you are likely to find that
the ISO C++ also goes off into the wilderness in the next few years just
like ISO BASIC.

Somewhere along the line ISO C and C++ have lost their way and I am not
sure how to get them back.

When Dr. Feynmann presented QED to a room including Pauli and Einstein,
the former suggested that it interfered with the latter's relativity
theory, to which Professor Einstein replied, "the theory is still so
new." When the zero-option was proposed, nobody took it seriously until
Reykjavik, when it was implemented. Point is, history takes a long
time. frank