C 99 compiler access

[Douglas A. Gwyn]

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)

Last time I looked, MISRA-C was a set of programming guidelines,
not a compiler specification.

Anyway, there are several compilers that have incorporated C99
features, on a path to full compliance.

 

[Douglas A. Gwyn]

I have heard several C standards people express exactly that thought.

I haven't heard any.

 

[Douglas A. Gwyn]

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

No, there aren't "a lot of problems with the maths".
There were a couple of minor issues with the
specification of some functions which were addressed
by technical corrigenda. The actual mathematics is
okay.

You appear to have a personal agenda that includes
torpedoing the C standard. Could this be related to
your notion that we should have allowed type int to
be only 8 bits wide?

 

[Douglas A. Gwyn]

I know some people with real concerns about
some parts of the C99 model. (their job is in validation)

I'm not sure what you mean by "C99 model", but there
is no essential difference from C89 in any of the
fundamentals, so whatever criticism there may be
would not be specific to C99.

My guess is that this refers to the continual UK
complaint about "too much undefined and unspecified
behavior". There are solid reasons for most of the
existing specifications involving these, which have
been explained in comp.std.c on numerous occasions.

Not even the // are supported in the same way. :-(

Really? If they can't follow the spec for even such
a simple feature, why would you trust those compilers
at all?

 

[CBFalconer]

.... snip ...

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)

I expect that is because there is significant competition in that
field, inasmuch as gcc is apparently not very tolerant of
restricted devices, such as 16 bit integers.

 

[CBFalconer]

.... snip ...


Also the Tasking Tricore compiler.

Has anyone actually validated these two/three compilers?

Never heard of TT. I believe the Dinkum effort is a library, not
a compiler. Comeau uses it. I think Comeaus system outputs C90
tuned to specific compilers, not executable code.

 

[David Hopwood]

Used with caution they're no worse than any other auto variable.

Not true. Because auto variables are constant size and recursion can be
limited, it may be the case on a particular platform that a given program
will *never* have undefined behaviour due to a stack overflow. This is
very unlikely to be true if the program uses VLAs, because the main point
of using VLAs is to allocate objects of arbitrary sizes.

Preferring malloc to VLAs because of this error handling problem is
entirely justified.

David Hopwood <[email protected]>

 

[Fred J. Tydeman]

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

Why do you think you need true float or true double support?
Set FLT_EVAL_METHOD to 2 and do (almost) everything in long double.
The only time (that I know of) you need true float or true double is
for: assignment (which is going to be a stor to memory anyway) and
cast (which I grant you is a pain to do a store/load via memory).
---
Fred J. Tydeman Tydeman Consulting
(e-mail address removed) Programming, testing, numerics
+1 (775) 287-5904 Vice-chair of J11 (ANSI "C")
Sample C99+FPCE tests: ftp://jump.net/pub/tybor/
Savers sleep well, investors eat well, spenders work forever.

 

[Richard Tobin]

Preferring malloc to VLAs because of this error handling problem is
entirely justified.

Unfortunately, on all the platforms I - and many others - use,
malloc() has just the same problem.

-- Richard

 

[David Hopwood]

Unfortunately, on all the platforms I - and many others - use,
malloc() has just the same problem.

You mean malloc() causes undefined behaviour when there is insufficient
memory? Get a better platform.

David Hopwood <[email protected]>

 

[Richard Tobin]

You mean malloc() causes undefined behaviour when there is insufficient
memory?

I mean malloc() may return a non-null value and then fail when you
try to actually use the memory. Presumably you already know about this.

Get a better platform.

For me, the behaviour of malloc() is not the only consideration in
choosing a platform.

-- Richard

 

[Joseph Myers]

Why do you think you need true float or true double support?
Set FLT_EVAL_METHOD to 2 and do (almost) everything in long double.
The only time (that I know of) you need true float or true double is
for: assignment (which is going to be a stor to memory anyway) and
cast (which I grant you is a pain to do a store/load via memory).

Assignment isn't necessarily going to be a store to memory in the
presence of optimisation. (There is indeed an existing option
-ffloat-store which forces it to be a store to memory, at significant
performance cost; it isn't currently enabled by the conformance
options.) There are old architectural issues around the x86 floating
point support, and while I have some notion of how they can be fixed,
I don't have the expertise in those areas of the compiler to allow for
fixing them (and producing a design for a fix that gets generally
accepted) in a time estimate for C99 support. FLT_EVAL_METHOD is set
to 2, though it should actually be set to -1 (another consequence of
those issues: sometimes the excess precision of intermediate
computations can be lost), but casts of expressions to the same type
do not do anything. (While C99 seems to say that when a float being
stored with the range and precision of long double is converted to
double, the excess range and precision is not removed, though it would
be when a double is converted to double.) So the estimate instead
considers everything not specific to a particular CPU target; almost
all CPUs supported by GCC do not have these problems.

 

[David Hopwood]

I mean malloc() may return a non-null value and then fail when you
try to actually use the memory. Presumably you already know about this.

You mean overcomittment of virtual memory, then? The behaviour in that
case is not entirely undefined; most platforms that overcommit virtual
memory will start killing processes, but will not cause them to have
otherwise undefined behaviour.

David Hopwood <[email protected]>

 

[James Kuyper]

I mean malloc() may return a non-null value and then fail when you
try to actually use the memory. Presumably you already know about this.

On the platform I use at work (IRIX on an SGI machine) that behavior
is controlled by a configuration parameter. The first time it caused a
problem, we tracked it down, roundly criticized the idiot who turned
that feature on, and got the SAs to turn it off.

 

[Robert Gamble]

ERT: Not really an assertion, just pointing out that from the
documentation a reasonable person could easily walk away with the
implication that full support is there. I think that even after reading
the parts referenced below this is a reasonable interpretation, although
apparently incorrect.

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.

I read all of the document but didn't find anything that really
contradicted my interpretation. Even the parts you pointed out don't
clearly state anything one way or another. Is there a place where these
exceptions are documented? Making this information more prevalent may
prevent this type of confusion in the future.

Rob Gamble

 

[CBFalconer]

.... snip ...
(While C99 seems to say that when a float being stored with the
range and precision of long double is converted to double, the
excess range and precision is not removed, though it would be
when a double is converted to double.) ... snip ...

That make absolutely no sense. I don't believe in quantum
creation of bits on demand.

 

[Chris Hills]

Last time I looked, MISRA-C was a set of programming guidelines,
not a compiler specification.

It is a coding guideline.

My point was that most of the worlds embedded compiler suites are making
their library code MISRA-C compliant because they think it is a Good
Idea (commercially).

Remember that MISRA-C was launched, from nowhere, as a small industry
specific guide, in 1998.

On the same line very few of the worlds compiler writers are making
their compilers C99 compliant (with any real effort) despite the fact
they knew it was coming and despite the fact that in theory it is the
specification for their compilers.

This is VERY sad.

There is no impetus or requirement by the majority of C programmers, or
their companies to have a C99 (or an ISO-C per-say) compiler.

BTW this is one of the reasons why MISRA-C2 (launched next month) is
still referring to C90+TC's because in reality that is what 98% of its
target market is using.

So the question is how do re create an environment in the Industry in
general where ISO-C is automatically considered a prerequisite for a
compiler?

We need to foster the idea among programmers and their managers that
ISO-C [C99] is a necessity for their compilers.

Anyway, there are several compilers that have incorporated C99
features, on a path to full compliance.

"several" "features" this is not good enough. We need "most" and "full
compliance"

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

I expect that is because there is significant competition in that
field, inasmuch as gcc is apparently not very tolerant of
restricted devices, such as 16 bit integers.

Yes, there is a lot of competition in the embedded world. From 4 to 128
bit. There is also Gcc and many other free tools for most embedded
platforms.

However whilst they are "rushing" to make their library code MISRA-C
complient (in as much as it can be) they are not rushing to make their
code their compilers C99 compliant...

This is strange. MISRA-C is "just a coding guideline" NOTE "guideline"
not "Standard" whereas ISO-C is THE standard for their compiler.

The problem is that the ISO-c standard is not seen as important or a
prerequisite for a compilers by the industry.

How do we change this perception? How do we get the industry to demand
ISO-C compliant compilers?


Part of the problem is a large part fot he industry uses GCC because
"its free and you get the source" rather than for any Engineering
reasons.

I suspect that until the law or the insurance companies REQUIRE ISC-C
complient compilers they will not become essential in the industry.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

A small off-topic quibble: It's Ada, not ADA. (The name isn't an
acronym.)

Thanks



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

I haven't heard any.

It was at a UK panel meeting.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/