C 99 compiler access

[CBFalconer]

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.

 

[Dan Pop]

That is absolutely untrue.

Then, please explain the lack of interest in C99 among the C programming
community at large.

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.

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]

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

 

[Joseph Myers]

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.)

 

[E. Robert Tisdale]

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?

 

[E. Robert Tisdale]

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?

 

[CBFalconer]

.... 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.

 

[Keith Thompson]

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.

 

[Chris Hills]

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.

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 /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

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 /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

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 /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

... 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 /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

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?

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 /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

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 /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

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 /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

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 /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Joseph Myers]

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.)

 

[Ben Pfaff]

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.

 

[Keith Thompson]

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.)

 

[Douglas A. Gwyn]

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".