What's the deal with C99?

[Eric Sosman]

Nonsense. You don't substantiate even *one* counter-claim.

What substantiation do you offer for "They did not attempt
to assess the implementability of C99?" Note that you have not
claimed their assessment is wrong -- that might be a matter of
opinion -- you have claimed that no assessment was even attempted,
and that is a matter of objective fact. Substantiation, please.

What substantiation do you offer for "They did not assess
the value of each feature to actual programmers?" Again, it is
not sufficient that you offer opinion about the accuracy of such
an assessment, you have claimed that no assessment was made,
faulty or otherwise. Substantiation, please.

What substantiation do you offer for "They did not seek to
encode features that programmers need or want?" Once again, a
contention that C99's features are not needed or wanted does not
suffice to support your claim; you have claimed that they did
not even seek to do right, not that they sought and failed.
Substantiation, please.

 

[jacob navia]

While it's not too hard to handle simple complex arithmetic yourself,
the syntax you have to use is quite awkward, at least some of the
operations are apt to be implemented poorly (unless you're a numerical
analyst), and you end up having to implement the whole blessed math
library if you want to do actual math (as opposed to arithmetic), which
is definitely a non-trivial task.

I agree. But the same problem arises with decimal representation floats,
or fixed point floats, proposed by IBM and the embedded systems people.

lcc-win implements the only sensible solution: operator overloading
allows all possible kinds of numbers to be added WITHOUT changing
the language at all.

 

[Bartc]

I agree. But the same problem arises with decimal representation
floats, or fixed point floats, proposed by IBM and the embedded
systems people.
lcc-win implements the only sensible solution: operator overloading
allows all possible kinds of numbers to be added WITHOUT changing
the language at all.

That sounds a good idea.

But one problem some people might have is it being available only on
lcc-win. Even if available on another compiler (I'm not familiar with many)
it might done a different way.

So being tied to a single compiler (and presumably to a platform) might be
seen as a disadvantage.

The same scheme would have to be adopted by other compilers. Unless your
implementation has some magic switch which will convert source code with
your extensions into more standard C.

(I know, gcc also has loads of extensions and some of the same arguments
apply to those.)

 

[Walter Banks]

But its obvious from looking at the Intel effort and the gcc
effort (both groups, being *motivated* to implement C99) that
something stopped each of them.

One can hardly accuse GCC off being motivated to adhere to standards.

I agree. So what the hell is the committee planning on doing about
it? If you look through the mailing lists for gcc, you will find that
many vendors talk to them and influence them all of the time (I am
specifically thinking of WindRiver and AMD).

More to the point what motivated GCC to not be part of the
standards process.

w..

 

[CBFalconer]

.... snip ...

This is going to get even more complex as C support evolves for
specialized processor architectures. We have written one compiler
for a thread based embedded processor that cannot call main for
example. (no code is executed on reset)

I am having major problems imagining how such a machine is
constructed. Without executing code, how can reset even function?
Details please.

 

[CBFalconer]

.... snip about extensions ...

(I know, gcc also has loads of extensions and some of the same
arguments apply to those.)

Not if you run it with "gcc -W -Wall -ansi -pedantic". You can
replace -ansi with -std=C99 if you like.

 

[lawrence.jones]

Nonsense. You don't substantiate even *one* counter-claim.

You didn't substantiate even one of the original claims. Of course, I
happen to have been an active member of the committee who attended
nearly all the meetings, and I don't remember you attending even one.
So my unsubstantiated claims might be just a tad more credible than
yours.

[...] There is *no* part of C99 that
has not been implemented. Many parts were implemented before they were
standardized.

*Sigh*. *OBVIOUSLY*. But that's a ridiculously low bar.

But it belies your claim that implementability was not considered.

They had to make sure that the whole she-bang could be all done at
once.

Which it obviously can, since there are a number of fulling conforming
C99 compilers.

But its obvious from looking at the Intel effort and the gcc
effort (both groups, being *motivated* to implement C99) that
something stopped each of them. In the end you end up with just a
couple of marginal C99 implementations which can only do so because
they are so marginal that they don't have any backward compatibility
problems to deal with.

Hardly. According to Intel, their C compiler conforms to C99 except
that long double is not supported. I assume that means that they intend
to support long double in the future but have not gotten around to it
yet and didn't want to have binary compatibility problems down the road.
Otherwise, since there's no requirement that long double actually be any
longer than double, they could have just made it a synonym for double
and been fully conforming. In addition, I understand that there a
number of fully conforming implementations -- Comeau C w/ Dinkumware
library, IBM C for AIX, HP C, and SGI C -- at least some of which are
not "so marginal that they don't have any backward compatibility
problems to deal with."

You have to be kidding me. Complex numbers that are incompatible with
C++?!?!

They're not incompatible. They're different, but they're not
incompatible. It's not at all difficult to write code that is valid in
both languages.

Randomly positioned declarations?

Intermixed declarations and code was one of the most requested features,
probably second only to // comments. Many programmers really like
declaring at first use, no matter how "nonsensical" it seems to you.

[re. GCC not participating in the ISO standards committee being bad]

I agree. So what the hell is the committee planning on doing about
it?

That's not the committee's job. In fact, it would probably go against
the rules. Participation is open to all, but actively soliciting one
vendor would open the committee to complaints from other vendors who
were not solicited and raise questions about the fairness of the
process.

What? First of all, if you need to *deal* with complex numbers in a
non-trivial manner (like implementing trigonometry, or numerical
integration or something like that), you better *BE* good enough to
implement your own complex number library.

You don't need to know how to implement a library to know how to use
one.

And you are saying the embedded/driver applications have a great need
for really marginal and difficult to implement complex numbers?

No -- freestanding implementations (which is what most embedded/driver
applications use) are not required to implement complex. The committee
is not stupid, no matter what you think.

C++ is the *path* to take C forward. It means that the areas that
they carve out should be solved by them, and the C standard committee
should accept this fact. This is the only, and best way for them to
remain relevant. This lack of consideration for C++ has help *cause*
C99 to be ignored by end-users.

C99 made a concerted effort to remain compatible with C++ without either
reinventing C++ or giving up on making any enhancements to C. If you
want C++, you know where to find it, but true booleans and complex types
are quite useful in C without all the rest of the C++ baggage. And they
*are* compatible with C++; not identical, but compatible.

[various suggestions for future enhancements to C]

So make a formal proposal to the committee. It's easy to toss around
ideas, it's a lot of hard work to flesh out all the details, make sure
it's portable to all the environments C is used in, come up with the
appropriate "standardeese" to describe it, make sure you've covered all
the interactions with other parts of the standard, etc. The committee
members are all quite busy with their own ideas, thanks.

And that ignores what the C standard committee *should* do just for
sanity reasons (fix the ftell/fseek nonsense, fix the time APIs to be
non-static and >= 64 bits).

We can't change existing APIs in a way that would break binary
compatibility -- that would guarantee that no one implement it. (That's
why we were essentially forced to adopt long long rather than just
mandating that long be at least 64 bits.) The best we could do would
probably be to adopt ftello/fseeko, but that also requires adopting
off_t and requires much care to align with POSIX. Since most systems
already support POSIX, I'm not sure what the actual benefit would be.
Time handling is a known problem: the committee tried to address it in
C99, but it's complicated (there are lots of conflicting requirements)
and we weren't able to come up with a significantly better solution in
the time available. David Tribble has since done a lot of work in this
area (<http://david.tribble.com/letters.html>) and I expect his
proposals to receive serious attention in the next revision.

-Larry Jones

I don't think math is a science, I think it's a religion. -- Calvin

 

[lawrence.jones]

More to the point what motivated GCC to not be part of the
standards process.

Initially (back in the days leading up to C89), the GCC developers were
actively hostile to the standardization process (I'm not entirely sure
why), as illustrated by their initial implementation of #pragma. That
attitude is, thankfully, long gone and the current developers have made
significant progress in conformance, although it's disappointing that
standards compliance still isn't part of their mission statement. Being
an open source project, I'm sure there are logistical problems that
would have to be addressed for formal participation, but I don't think
that any of them are insurmountable. In particular, I would think that
the GCC steering committee could become a member of the ANSI committee
(DECUS was a member for quite a while), which would entitle them to one
Principal and unlimited Alternate representatives. Alternatively, WG14
meetings are always open to the interested public, no formal membership
is required (visitors are allowed to participate fully except for formal
votes). Funding for the membership and travel could be a problem,
though. In short, I suspect it's the usual open source problem: no one
is sufficiently interested to do it on their own and it's not a high
enough priority for the steering committee to encourage/direct someone
to do it.

-Larry Jones

Whatever it is, it's driving me crazy! -- Calvin

 

[lawrence.jones]

I agree. But the same problem arises with decimal representation floats,
or fixed point floats, proposed by IBM and the embedded systems people.

lcc-win implements the only sensible solution: operator overloading
allows all possible kinds of numbers to be added WITHOUT changing
the language at all.

That certainly is *a* sensible solution, but it wasn't one the committee
was prepared to require for C99. When you start looking at environments
outside your comfy little world (which you keep insisting don't exist),
there are lots of things to take into consideration. And creating a
standard specification for operator overloading would be a major task.

-Larry Jones

He doesn't complain, but his self-righteousness sure gets on my nerves.
-- Calvin

 

[Ioannis Vranos]

Bartc wrote:
... snip about extensions ...

Not if you run it with "gcc -W -Wall -ansi -pedantic". You can
replace -ansi with -std=C99 if you like.

AFAIK gcc -ansi is for C90 conformance and not C99, so the above are not
equivalent.

 

[CBFalconer]

AFAIK gcc -ansi is for C90 conformance and not C99, so the above
are not equivalent.

Exactly. I didn't say they were.

 

[Harald van Dijk]

Not if you run it with "gcc -W -Wall -ansi -pedantic". You can replace
-ansi with -std=C99 if you like.

"gcc -W -Wall -ansi -pedantic" and "gcc -W -Wall -std=c99 -pedantic" both
accept extensions, and Bartc's snipped arguments do apply.

 

[Keith Thompson]

AFAIK gcc -ansi is for C90 conformance and not C99, so the above are not
equivalent.

<OT>
He didn't say they were equivalent. "-ansi" specifies C89/C90
conformance; "-std=c99" (note lowercase) specifies (incomplete) C99
conformance.
</OT>

 

[santosh]

AFAIK gcc -ansi is for C90 conformance and not C99, so the above are
not equivalent.

This is the result of overly terse responses.

 

[jacob navia]

That certainly is *a* sensible solution, but it wasn't one the committee
was prepared to require for C99.

That is why I have proposed in comp.std.c my extensions
for consideration.

When you start looking at environments
outside your comfy little world (which you keep insisting don't exist),
there are lots of things to take into consideration.

Just polemic.

What little world?

Can you be more specific?

And creating a
standard specification for operator overloading would be a major task.

It is. I proposed one, and is far from complete.

So what?

Only easy stuff needs to be done?

 

[Bartc]

Not if you run it with "gcc -W -Wall -ansi -pedantic". You can
replace -ansi with -std=C99 if you like.

That's not what I meant. If say I used &&a to get the address of a label in
gcc, those options may simply report that use of && is non standard.

They won't help me use && in another compiler which doesn't have label
addresses.

A solution that runs on both compilers would need a different approach and
therefore the usefulness of that particular extension is lost.

Or I have to use clumsy code that is different depending on compilers.

In the case of operator overloading, the differences in source code could be
substantial.

 

[Ioannis Vranos]

Hardly. According to Intel, their C compiler conforms to C99 except
that long double is not supported. I assume that means that they intend
to support long double in the future but have not gotten around to it
yet and didn't want to have binary compatibility problems down the road.

long double is a fully supported built-in type of C90. I suppose you are
doing a mistake about this.

 

[santosh]

long double is a fully supported built-in type of C90. I suppose you
are doing a mistake about this.

And my installation of the Intel C/C++ compiler does seem to support
long double.

 

[Paul Hsieh]

What substantiation do you offer for "They did not attempt
to assess the implementability of C99?"

Because no major vendor has gone all the way with its C99 support,
even when they were highly motivated to do so (in particular, gcc and
Intel). They have the manpower, and they publicly announced their
intention to support C99 in principle. The only thing that stopped
them was the fact that its actually an extremely difficult thing to do
relative to the value of doing it.

[...] Note that you have not
claimed their assessment is wrong -- that might be a matter of
opinion -- you have claimed that no assessment was even attempted,
and that is a matter of objective fact. Substantiation, please.

Pretty much every vendor balked at it. It means there were enough
land mines in every direction that *no* vendor could implement the
whole thing. While making a reference compiler might have been too
much of an effort (but which would have been sufficient to discover
the problems), they clearly did not go half way either.

What substantiation do you offer for "They did not assess
the value of each feature to actual programmers?" Again, it is
not sufficient that you offer opinion about the accuracy of such
an assessment, you have claimed that no assessment was made,
faulty or otherwise. Substantiation, please.

Oh that's obvious. There are so *MANY* features that clearly need to
be in the language. The mass exodus from C (and C++) to go to other
languages by itself speaks volumes about what programmers want.
There's no feature added to C99 that addresses even one thing that has
been causing people leave C behind.

When you look at the things that *were* added, you realize, that its
for extremely narrow special interests. The committee was reacting to
a market that isn't there.

What substantiation do you offer for "They did not seek to
encode features that programmers need or want?" Once again, a
contention that C99's features are not needed or wanted does not
suffice to support your claim; you have claimed that they did
not even seek to do right, not that they sought and failed.
Substantiation, please.

I have to prove that the ANSI C committee never made requests that
made it to my ears, nor to the ears of my colleges? How shall I do
that? My evidence is that no such features, or attempts at such
features have been documented anywhere, unless someone *outside* of
the ANSI committee people typed it up.

The one feature that there simply is NO controversy about at all:
Memory management. I don't think programmers could yell any louder
for better support for any (practical) other feature. (Obviously the
other one is bounds checked arrays, however, that runs into
practicality problems.) Show me a document anywhere that demonstrates
that the ISO C language committee gave a flying fig about memory
management; that they were working towards some sort of library
extensions or API enhancements to deal with the leaking, corruption
and examination of memory.

The other obvious stuff like removing gets, or strtok -- the committee
continued to prop up these functions with rationales. While I
disagree with the main content of TR 24731, one of its features, which
is to provide re-entrant substitutes for many of the standard library
functions has been an issue ever since computers have supported multi-
threading. I.e., this issue is not recent -- and you can't call
Microsoft exactly a "fast mover" by using its influence to deal with
this issue *NOW*.

Where are the user surveys? Where is the honest and frank discussion
of other languages and their features and how C might address any such
feature gaps? What was the reaction to the Morris worm fiasco (from
the 1980s)?

*I* am just an interested person. *I* don't have to *prove* anything
to anyone. I don't have anything at stake. Unlike the ANSI C
committee, I don't need to justify my existence.

 

[jacob navia]

Because no major vendor has gone all the way with its C99 support,
even when they were highly motivated to do so (in particular, gcc and
Intel). They have the manpower, and they publicly announced their
intention to support C99 in principle. The only thing that stopped
them was the fact that its actually an extremely difficult thing to do
relative to the value of doing it.

I think all of C99 is easily implementable. As a data point, I would
like to point out that a single person, working hard, is able
to implement most of it in a period of years, even not working
all the time on it. See my small implementation at the URL below.

In many points of your critique of the C99 standard you are right Paul,
but I do not think that this one (difficulty of implementing it) is
a good point.

jacob