What's the deal with C99?

[Morris Dovey]

We need one programming language for everything except the nichiest of niche
areas.

Yes! Let's call it "expiranto" and make sure that there's
provision for inlining, not just assembly code, but all other
programming languages - Algol, APL, BASIC, C, C++, COBOL, Dibol,
FOCAL, Forth, Fortran, ... , SNOBOL, ad nauseum (ad infinitum!)

8-]

 

[santosh]

We need one programming language for everything except the nichiest of
niche areas.

This is an idealistic but naive view. Firstly no one language is going
to satisfy the preferences of all (or even most) programmers. Secondly,
a language that makes X easy to implement is likely to make Y difficult
to implement, and those who make a living implementing Y are not going
to be pleased. Thirdly the requirements that such a "universal"
language would have on the translator and on the supporting systems
would be very heavy, thus restricting it's use in resource constrained
systems. Fourthly I quail at the mere thought of the size of the
library API that this dream language of Malcolm's must be. Also a
single language is going to struggle to implement within it all the
various programming paradigms and designs.

What we need is a well defined infrastructure that makes creating
multi-language systems a breeze. Even this much is a very complex
endeavour as is shown by the problems with CORBA.

<snip>

 

[Keith Thompson]

We need one programming language for everything except the nichiest of
niche areas. I've over twenty years programming
experience. Occasionally I have to knock up little Perl scripts. I
find myself puzzling over the Perl handbook trying to work out how to
break out of a loop, or how to sort a list of files by
suffix. Essentially Perl does these things in the same way as C, but
with tiny differences to make it look more like a Unix shell script,
or maybe just to be different to emphasise that it is not C. It's a
huge waste of time. As I said, this is someone with 20 years
experience who can't get his tool to sort files by suffix. However
useless the individual concerned, that would be unacceptable in any
other industry. You wouldn't tolerate eningeers being unable to
calculate bolt tolerances because someone had suddenly decided to use
a weird and wonderful new measuring system, or lawyers unable to read
new legislation because the Federal government had decided on
Latin. However we toleratye the same in software.

Both of these things are very straightforward in Perl, which is after
all a different language than C.

Realistically, we're a *long* way from being able to have a single
programming language for everything. Different languages have
different design philosophies; coherence of design within a language
is seen (rightly, in my opinion) as more important than syntactic
consistency across languages. Perl uses "last" rather than "break" to
break out of a loop; it goes along with "next" to quit the current
iteration and start from the top, like C's "continue". As for sorting
a list of files by suffix, the built-in "sort" operator makes that
quite straightforward, and quite similar to the way you'd do it in C
(write a comparison function that compares the two suffixes and pass
it to the built-in sort operator in Perl or the qsort() function in
C).

And if someday we do have a single universal programming language, I
somehow doubt that it's going to be C.

 

[Malcolm McLean]

Both of these things are very straightforward in Perl, which is after
all a different language than C.

That's the point. These things are straightforwards, unless you happen not
to know how to do them. Then either you ask someone or, if that isn't
practical, it takes fiddling and messing about until you finally work out
that "last" is just Perl's "break", or something equally similar.
It's the fiddle, get to work, rationalise as teething problem cycle that
we've got to break. Using new software packages is not "teething". It is a
constant situation. All the time some fancy new compiler, stupid new
language, new drawing package or whatever comes out, and there is no option
but to use it.

 

[lawrence.jones]

Well I don't about "rejected", but it's true that it has not been
received with anywhere near the enthusiasm that C90 was received.

Very few standards have been.

-Larry Jones

Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. -- Calvin

 

[Ioannis Vranos]

Maybe C should follow what ISO did for Pascal and include features that
are (or might be) poorly implemented into an "extended" standard for
the language, with the core standard being more or less frozen around
C95?

Then nearly all implementors could have the satisfaction of labelling
their products "fully conforming to the Core C Standard" while
ambitious vendors could implement "the extended C Standard". This way
programmers who want their source to be maximally portable could stick
to the core standard while simultaneously those who want to use widely
implemented but not ubiquitous features could write to the extended
standard.

Features like VLAs, complex arithmetic, fenv.h etc. could be moved to
the extended standard and widely available things like APIs for
traversing directories etc., could be added to it, without
necessitating that either all implementations implement them or risk
being labelled "non-conforming".

This is a dead end. Pascal is a dead language and I think one of the
main factors is that there are two standards for it. I think the only
way for C to survive is C1x is to be based on C95, adopt the most
widely-adopted C99 features and reject the rest. And in its "foreword"
it should contain a similar phrase that C++03 has:


"This second edition cancels and replaces the first edition (ISO/IEC
14882:1998), which has been technically revised".



for example something like:

"This technically revised standard cancels and replaces the ISO/IEC
9899:1999".

 

[lawrence.jones]

When ISO introduced the C99 standard, the situation was different.
The C programming community *already* had a standardized language, and
it worked well enough for most purposes.

The other thing that people forget is that in 1989, there were *lots* of
competing C compiler vendors, particularly in the MS-DOS world, and ANSI
C conformance was seen as a valuable competitive advantage. The market
has since consolidated to the point where there are rarely more than two
compilers for any particular platform (usually GCC and the vendor's
compiler), and C99 conformance isn't likely to affect the decision of
which one to use.

-Larry Jones

I wonder if I can grow fangs when my baby teeth fall out. -- Calvin

 

[lawrence.jones]

If, as you say, most of the C programming community had a standard with
which they were well pleased and the compiler vendors were pleased that
most of their user base was pleased, why was there another standard at
all? Who were the main driving force behind C99?

The portions of the programming community/customer base that *weren't*
well pleased. The high-performance computing community saw some
significant barriers to optimization that they wanted to fix. The
numerical community wanted additional mathematical features. The
multinational community wanted better multilingual support. And so on.

The committee tried to determine which of the many requests would be
sufficiently useful to a large enough portion of the C programming
community to justify "forcing" every implementor to support them. I
think we did a reasonable job of that, but others will certainly
disagree. What we didn't anticipate is that there are very few vendors
whose customer base encompases all of those communities and who thus
felt compelled to implement all of C99. Instead, each vendor has
implemented just those pieces that are important to their customer base
leading to multiple de facto subsets of C99, something the committee has
always been strongly against (even the original bifurcation into
freestanding and hosted environments was hotly debated).

-Larry Jones

Wheeee. -- Calvin

 

[Keith Thompson]

That's the point. These things are straightforwards, unless you happen
not to know how to do them. Then either you ask someone or, if that
isn't practical, it takes fiddling and messing about until you finally
work out that "last" is just Perl's "break", or something equally
similar.
It's the fiddle, get to work, rationalise as teething problem cycle
that we've got to break. Using new software packages is not
"teething". It is a constant situation. All the time some fancy new
compiler, stupid new language, new drawing package or whatever comes
out, and there is no option but to use it.

And other natural languages are hard (try Finnish), and they use funny
characters (7-bit ASCII is so much simpler than Unicode).

And I can't run my Linux executables under Windows, or my old PDP-11
programs on an IBM mainframe.

And your solution is ...?

 

[jacob navia]

Using new software packages is not "teething". It is
a constant situation. All the time some fancy new compiler, stupid new
language, new drawing package or whatever comes out, and there is no
option but to use it.

Not really.

WHY you have to use it?
I still use word 97. It is quite OK.
I still use vi

One of the things you could learn is that you do not have
to use it. It is up to you!

But, that aside, you are proposing that software production
disappears? I mean your BASIC interpreter, is *also* a
new "fancy" version of BASIC.

 

[Malcolm McLean]

Not really.

WHY you have to use it?
I still use word 97. It is quite OK.
I still use vi

One of the things you could learn is that you do not have
to use it. It is up to you!

Not really. Most programmers don't have control over the operating system
they use at work, or the platform that they write for, or the language that
they write in.
I had planned to do my diagrams in Powerpoint, for instance. I knocked up a
nice diagram, but it was saved at only 700 pixels resolution. The text was
pixellated. There's a way round this problem with version 3.0, but we're
still on version 2. Pixellated text was not acceptable. So now I'm using
Coreldraw, another new program. This is the constant situation.

But, that aside, you are proposing that software production
disappears? I mean your BASIC interpreter, is *also* a
new "fancy" version of BASIC.

Yes, I've got to admit that I tweaked Basic because the canonical read /
data paradigm is just so hard to use. So I allow initialised dimensioned
arrays. So I'm also guilty.

 

[Ian Collins]

This is a dead end. Pascal is a dead language and I think one of the
main factors is that there are two standards for it. I think the only
way for C to survive is C1x is to be based on C95, adopt the most
widely-adopted C99 features and reject the rest.

There you have a problem. The C standard is cited and included by
reference in a number of other standards (C++ and POSIX for example).
So removing features from the language would have knock on effects way
beyond the C standard and existing C code.

 

[Flash Gordon]

Malcolm McLean wrote, On 24/03/08 20:24:

That's the point. These things are straightforwards, unless you happen
not to know how to do them. Then either you ask someone or, if that
isn't practical, it takes fiddling and messing about until you finally
work out that "last" is just Perl's "break", or something equally similar.

There is this concept called learning about a tool before attempting to
use it. I had to learn hot to use a lathe. Then, when I had to use a
horizontal mill I found it did not work the same! Well, actually I was
taught how to use it and it did not work the same. Casting aluminium was
different again!

It's the fiddle, get to work, rationalise as teething problem cycle that
we've got to break. Using new software packages is not "teething". It is
a constant situation. All the time some fancy new compiler, stupid new
language, new drawing package or whatever comes out, and there is no
option but to use it.

I've never needed to use a new language or package just because it has
come out. Sometimes I have *chosen* to use the latest wizzy whatever,
but not normally.

 

[Flash Gordon]

Malcolm McLean wrote, On 24/03/08 21:36:

Not really. Most programmers don't have control over the operating
system they use at work, or the platform that they write for, or the
language that they write in.

True, and the times when it is the fancy new whatever that they are told
to use are few and far between. So in fact the situation is normally
exactly the reverse of what you have claimed.

I had planned to do my diagrams in Powerpoint, for instance. I knocked
up a nice diagram, but it was saved at only 700 pixels resolution. The
text was pixellated. There's a way round this problem with version 3.0,
but we're still on version 2. Pixellated text was not acceptable. So now
I'm using Coreldraw, another new program. This is the constant situation.

Ah, so you mean you did not check to see if a program met your
requirements before deciding to use it and then got upset that you had
to switch to something else.

Yes, I've got to admit that I tweaked Basic because the canonical read /
data paradigm is just so hard to use. So I allow initialised dimensioned
arrays. So I'm also guilty.

Last I looked you were also guilty of not including a number of things
most programmers would consider essential for any serious language.

 

[Ioannis Vranos]

There you have a problem. The C standard is cited and included by
reference in a number of other standards (C++ and POSIX for example).
So removing features from the language would have knock on effects way
beyond the C standard and existing C code.

Well C++03 hasn't any reference on C99 yet. Also we should concentrate
on C here.

C++ isn't going to adopt _Complex and the most of the rest ridiculous
built-in stuff, because it aims to generality and abstraction. That is
it implements special-purpose tools (like a complex type) by using
general-purpose programming facilities.

So I think we should concentrate on C here.

 

[Ioannis Vranos]

My message corrected, because it was insulting for the efforts of those
who participated in the creation of C99, and probably also to the person
I replied with this post:

Well C++03 hasn't any reference on C99 yet. Also we should concentrate
on C here.

C++ isn't going to adopt _Complex and the most of the rest special-purpose

 

[Malcolm McLean]

Malcolm McLean wrote, On 24/03/08 21:36:

Last I looked you were also guilty of not including a number of things
most programmers would consider essential for any serious language.

You don't actually need subroutines to write even complex programs. It is
just that many programmers are so used to "structured programming" that they
think it is the only game in town.
I considered including procedures, with parameters and local variables but
rejected them because one of the design goals was that the source should fit
into a single reasonable length C file. At 3000 lines it was pushing
reasonable length. Gosub could have been incorporporated with only minor
additions, but without names, parameters or local variables the statement is
essentially useless, and so I left it out.

The idea was that MiniBasic would be used to provide softcoding or scripting
for larger programs, so the user would only write a single function, or,
asin BASUCdraw, just the drawing logic. In fact it seems to have found its
niche in small embedded apps.

 

[Paul Hsieh]

We're currently in the undesireable situation of having a rejected
standard, C99, which means that "standard C" is no longer the precise
thing it once was.

Correct. It totally undermines the value, status and meaning of the
standard and the standards committee itself. C90 is the standard.
C99 is some strange document that really doesn't mean anything.

[...] That doesn't mean it is impossible to hold a coherent discussion.

Indeed! People have actually posted here with answers to questions
that apply only to C99 and not C90! I.e., answers are given to
questions that actually cannot be used in practice! Who needs to do
actual programming anyways?

[...] I
don't think we can legitimately hold C99 to be off-topic, but we should
point out that non-block top declarations are not, de facto, portable.

Oh worse than that, they are pointless in a non-C++ environment.
"Declare anywhere" is a very specific work around in C++ to allow you
control over the order that constructors are called.

By their nature they heavily degrade the readability of code. If you
see a variable and want to know what type it is, you have to scan the
code sequence leading up to its use, rather than just the declaration
blocks.

I've looked at the differences in C99 according to the Wikipedia C article.

It doesn't look like that much to add to C90.

The variable length arrays were apparently killer to gcc. The whole
gcc porting effort was stopped because of that and other reasons.

So why the problem with creating compilers for it, is it motivation?

Primarily its because the standards committee has totally lost touch
with the real world of computer programming.

They did not, 1) attempt to assess the implementability of C99. They
also did not 2) assess the *value* of each feature to actual
programmers. And finally they did not 3) seek to encode features that
programmers need or want.

What is the most difficult part of C99 to implement?

Well, in the case of gcc, apparently the variable length arrays are
fatal, because some critical amount of the code out there that uses
gcc relies on the specific gcc semantics which conflict with C99's
VLAs.

Some of the extensions, like Complex support (I've never used complex
numbers and never will, and I'm sure many others will say the same) are
really not very interesting; perhaps that should have been optional if it
made producing the compilers easier.

Not only is it almost entirely useless (who the hell can't program up
their own complex numbers for crying out loud!), it conflicts with the
C++ template (namespace-wise) which does the exact same thing but is
more general (and therefore the C99 version *cannot* be taken forward
to C++).

Or is the real problem that there will always be C compilers that are not
C99 compatible,

By itself that is not an argument against C99. Many compilers did not
implement C90 or C89, however, we still consider C90 the de facto
standard because it was implemented by most compilers, and certainly
all the most popular ones. In fact being C90 compatible itself pretty
much assured compiler vendors that they would have *some* audience.

C99's failure is traceable most directly to the failure of the
committee to make a compelling enough standard to get sufficient by-in
by compiler vendors, or even programmers (who would, in turn, put
pressure on compiler vendors.) A good recent comparative example of
this is how the C++ standard was diligently implemented by most
vendors *except* Microsoft. Then bowing to user pressure, Microsoft
eventually acceded to their demands and they have implemented a fairly
compliant C++ compiler.

C99 isn't there. And C0x promises to do no better. In their
stupidity, the standards committee are listening to Microsoft, rather
than Microsoft's customers as to what to add to their next standard
and now we have this ridiculous "safer C library" nonsense that
everyone hates. I don't know of a single person anywhere who uses the
Visual C++ who doesn't turn off these new "safer" library functions,
and the false "deprecation" warnings they now emit. The C language
committee just happily endorses this even though Microsoft has made no
commitment to even implement the C99 standard.

[...] effectively breaking the standard because any supposedly
portable C99 code (does anyone else keep typing it as C((?) will not be
portable to those compilers?

Of course -- coding to C99, or *near* C99 breaks portability, because
there isn't a common subset of C99 that everyone pretty much agrees
on. The only real common denominator is C90 minus the new reserved
words in C99. In which case, why not just stick with C90? I think
the jury has spoken -- C99 doesn't give a reason for abandoning C90
and what portability it provides.

 

[Ian Collins]

Paul Hsieh wrote:

[mixed code and declarations]

Oh worse than that, they are pointless in a non-C++ environment.
"Declare anywhere" is a very specific work around in C++ to allow you
control over the order that constructors are called.

By their nature they heavily degrade the readability of code. If you
see a variable and want to know what type it is, you have to scan the
code sequence leading up to its use, rather than just the declaration
blocks.

It's pretty clear that this is a matter of opinion. Some of do prefer
to introduce variables when they can be meaningfully initialised. Loop
indexes are an obvious instance.

 

[Ben Pfaff]

I think the only
way for C to survive is C1x is to be based on C95, adopt the most
widely-adopted C99 features and reject the rest. And in its "foreword"
it should contain a similar phrase that C++03 has:


"This second edition cancels and replaces the first edition (ISO/IEC
14882:1998), which has been technically revised".

You mean, the same way that C99 contains the sentence, "This
second edition cancels and replaces the first edition, ISO/IEC
9899:1990, as amended and corrected by ISO/IEC 9899/COR1:1994,
ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996."