Where to download C99 Standard

[Seebs]

So what I think ISO is looking at doing is making optional the things
that "most" compilers don't use. So we can get back to a core language
that everyone uses.

That makes sense. And much though I like VLAs, I do see foundational
problems with using them in some domains, so I can see them being a thing
not everyone uses.

That said, I'd distinguish between "most compilers don't use them" and
"a few compilers don't use them". I don't know that I've seen a compiler
in a long time that doesn't support VLAs. I suppose MS's doesn't, but
I have had such consistently negative experiences with their compilers
that I really, really, don't care what they support.

-s

 

[jacob navia]

Le 03/01/11 21:25, Richard a écrit :

You can "see" that can you?

Amazing.

Probably about 1% of C programs use them.

You're amazing!

VLAs allow you to use exactly as much memory as you need, not
more, not less. This way you use the stack sparingly. Instead of

int table[MAXLENGTH];

that will be too big in 99% of the cases you just use as much stack
as you actually need.

But obviously, since "THERE IS NO STACK IN C" and "C HAS NO STACK"
etc, they are useless.

 

[Keith Thompson]

That is my point. No one fully implemented C99. Most implemented "some"
features"

So what I think ISO is looking at doing is making optional the things
that "most" compilers don't use. So we can get back to a core language
that everyone uses.

By "compilers don't use, do you mean "compilers don't implement", or
"programmers don't use"?

Was the choice of these two particular features, complex types and VLAs,
made more on the basis of use by programmers than on the basis of
support by compilers?

The 2004 C-Bed proposal was to have a small (C95 like) core and make
additional things optional in various appendices. So all compilers
could then validate to C-XX "with Appendix 1,3,6" etc as required.

I don't think I've ever heard of this "2004 C-Bed proposal". Can you
provide a reference to it?

 

[Chris H]

By "compilers don't use, do you mean "compilers don't implement", or
"programmers don't use"?

Compilers don't implement

Was the choice of these two particular features, complex types and VLAs,
made more on the basis of use by programmers than on the basis of
support by compilers?

No idea.

I don't think I've ever heard of this "2004 C-Bed proposal". Can you
provide a reference to it?

Not externally. It is on my hard drive and we discussed it in the UK.

 

[Keith Thompson]

Compilers don't implement

Ok, so what exactly did you mean?

No idea.

I'm surprised by that. I would have thought you'd have been part of
the discussion.

 

[Marcin Grzegorczyk]

Everyone has done partial implementations (including GCC). No one in the
main stream has done full implementations. The problem is the C99 added
a hell of a lot of stuff no one wanted.

IMHO, GCC clearly aims for a full implementation. The problem is, some
C99 features require a pretty intimate relationship between the compiler
(including the preprocessor) and the library, which does not sit well
with the traditional GCC's "library is someone else's problem" model;
math_errhandling and the standard pragmas are good examples.

 

[Marcin Grzegorczyk]

Are there plans to make any more C99 features optional, or will it
be just VLAs and complex types?

The two relevant documents are:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1460.htm
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1471.htm

At the Colorado 2010 meeting, N1460 was accepted (so that's what is in
the latest draft) and N1471 was directed for review; so far, I haven't
seen any information on whether it is going to be put forward again.

 

[Keith Thompson]

The two relevant documents are:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1460.htm
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1471.htm

At the Colorado 2010 meeting, N1460 was accepted (so that's what is in
the latest draft) and N1471 was directed for review; so far, I haven't
seen any information on whether it is going to be put forward again.

Thanks!

I have some comments on the wording, which I'll post to comp.std.c.

 

[Chris H]

IMHO, GCC clearly aims for a full implementation.

And fails.

The problem is, some C99 features require a pretty intimate
relationship between the compiler (including the preprocessor) and the
library, which does not sit well with the traditional GCC's "library is
someone else's problem" model; math_errhandling and the standard
pragmas are good examples.

Yes which is why for most targets gcc is a poor choice.

 

[Chris H]

I'm surprised by that. I would have thought you'd have been part of
the discussion.

I have been far too busy with work and MISRA-C to keep up with every
detail of ISO-C these days also one of the MISRA team who has more time
is watching the details of ISO.

 

[Seebs]

Yes which is why for most targets gcc is a poor choice.

Well, I'm obviously biased, since we do embedded Linux, but we've not found
this to be a problem in practice. It generates code, the code usually works,
and people seem happy with it.

-s

 

[Walter Banks]

What PJP did propose was to identify the core features of C. The context of the
comments was important. This was at a time that ISO/IEC 18037 and the decimal
math standards were becoming standards. It was clear to everyone at WG14 that
these two TR's were not needed by everyone. The real question was if the TR's
were optional, what were the core features of C?

[...]

Are there any documents available online that discuss
the rationale for this? Probably something under
http://www.open-std.org/jtc1/sc22/wg14/www/docs/, but there are a
lot of documents there.

I talked to PJP in Markham about the core components of C.
There are two short documents that PJP wrote on standard subsetting.
N1443 and N1460 These are the conditional defines that other have
mentioned.

Regards,

w..

 

[Keith Thompson]

What PJP did propose was to identify the core features of
C. The context of the comments was important. This was at a
time that ISO/IEC 18037 and the decimal math standards were
becoming standards. It was clear to everyone at WG14 that
these two TR's were not needed by everyone. The real question
was if the TR's were optional, what were the core features of C?

[...]

Are there any documents available online that discuss
the rationale for this? Probably something under
http://www.open-std.org/jtc1/sc22/wg14/www/docs/, but there are a
lot of documents there.

I talked to PJP in Markham about the core components of C.
There are two short documents that PJP wrote on standard subsetting.
N1443 and N1460 These are the conditional defines that other have
mentioned.

N1460 appears to be an updated version of N1443.

N1471, mentioned here previously, proposes three additional optional
features; it hasn't been adopted in the latest draft. The author
is S. J. Montgomery, apparently from the MISRA C WG.

 

[Walter Banks]

N1460 appears to be an updated version of N1443.

N1471, mentioned here previously, proposes three additional optional
features; it hasn't been adopted in the latest draft. The author
is S. J. Montgomery, apparently from the MISRA C WG.

Steve Montgomery who has a lot to say about coding standards
and feature sets. He represented misra at WG14


N1460 was updated for a later meeting. There was a lot of break time
discussions over language subsetting at a few meetings. The
conversations we had in Markham all agreed that it was a good idea,
the hard part was trying to find realistic subsets. I went away from the
Markham meeting determined to find some voice for the needs of
embedded systems applications that could be identified so the
development costs of tools could be lowered and more important
tool developers could focus on core requirements. The problem is
in the details, every set I looked had more complexity than the full
standard being replaced.

It was clear that the TR's were optional right from the beginning.

What next?
Drop floating point from embedded systems?

What about integer sizes? This was a battle won and lost creating
size specific integers in C99.

You can look at the language core and start from that side with
the essential C features.

Basic syntax.
Operator precedence
. . .
after the obvious list, again it is a series of tough choices.


There are a lot of C users here.

What is the core of the language that must be available, remembering that C is used in many contexts?

Regards,

w..

 

[jacob navia]

Le 04/01/11 22:31, Walter Banks a écrit :

What next?
Drop floating point from embedded systems?

What about integer sizes? This was a battle won and lost creating
size specific integers in C99.

You can look at the language core and start from that side with
the essential C features.

Basic syntax.
Operator precedence
. . .
after the obvious list, again it is a series of tough choices.


There are a lot of C users here.

What is the core of the language that must be available, remembering that C is used in many contexts?

Regards,

Why not do what the so often cited n1395 proposed?
Define a subset of C that is a new language subset
in a new document, called CSI as they propose
(Conforming Subset Implementation) without
floating point.

That would mean dropping complex and tgmath.h and most math functions
from the math library, dropping some formats from the printf
specifications and other library changes probably.

THAT was the proposal from the Netherlands committee, NOT to change
the whole language dropping most of C99 and dooming C to just a
niche language for micro controllers.

OK, your company makes money with that kind of stuff. It is OK.

But maybe you acknowledge that there are OTHER companies that
make money in OTHER kinds of environments?

Why do you want to ignore any other uses of C?

Why coudn't you propose a subset of C consisting of:

Standard language except the types

float, double, long double

and all associated stuff: math.h and stdio that use double,
complex, and tgmath.h, etc.

THAT would be a REAL progress, i.e. define a non-floating point
subset of C for micro-controllers and very small machines that
does not use floating point. The long long type would be optional,
with short 16, int 16 or 32, and long 32.

That is a feasible language where you can do a LOT of stuff.

But WHY PUT ALL OTHER users of C out of the loop?

Why destroy the C99 standard?

Just think about it for a while. You feel that the standard did not
follow your needs. Why should NOW everyone else follow YOUR needs?

 

[Chris H]

What PJP did propose was to identify the core features of
C. The context of the comments was important. This was at a
time that ISO/IEC 18037 and the decimal math standards were
becoming standards. It was clear to everyone at WG14 that
these two TR's were not needed by everyone. The real question
was if the TR's were optional, what were the core features of C?
[...]

Are there any documents available online that discuss
the rationale for this? Probably something under
http://www.open-std.org/jtc1/sc22/wg14/www/docs/, but there are a
lot of documents there.

I talked to PJP in Markham about the core components of C.
There are two short documents that PJP wrote on standard subsetting.
N1443 and N1460 These are the conditional defines that other have
mentioned.

N1460 appears to be an updated version of N1443.

N1471, mentioned here previously, proposes three additional optional
features; it hasn't been adopted in the latest draft. The author
is S. J. Montgomery, apparently from the MISRA C WG.

Steve is the Chair of the MISRA-C WG. MISRA-C now has CAT-C liaison
with ISO-C WG

 

[Chris H]

THAT was the proposal from the Netherlands committee, NOT to change
the whole language dropping most of C99 and dooming C to just a
niche language for micro controllers.

They are the main group of users for C. On the PC and other non embedded
and hosted systems people have tended to C++ and other languages.

But WHY PUT ALL OTHER users of C out of the loop?

They are not out of the loop. The additional features are optional.

Why destroy the C99 standard?

The C99 standard is a standard in name only as already discussed that 12
years on no serious mainstream compilers have fully implemented it.

Many have a C94/5 compiler with C99 bits added. What is suggested is to
revise the Standard so that the core language is the one everyone uses
and the additional bit that some use is optional. That way the majority
of compilers will be C1* compliant and the standard will actually mean
something again.

Just think about it for a while. You feel that the standard did not
follow your needs. Why should NOW everyone else follow YOUR needs?

What is needed is a subset that will work for *everyone*. All
additional things would be optional thus it will meet everyone's needs.
You can still add extensions to your compiler.

 

[Walter Banks]

Le 04/01/11 22:31, Walter Banks a écrit :


Why not do what the so often cited n1395 proposed?
Define a subset of C that is a new language subset
in a new document, called CSI as they propose
(Conforming Subset Implementation) without
floating point.

That would mean dropping complex and tgmath.h and most math functions
from the math library, dropping some formats from the printf
specifications and other library changes probably.

THAT was the proposal from the Netherlands committee, NOT to change
the whole language dropping most of C99 and dooming C to just a
niche language for micro controllers.

The proposal was to identify core language details. Lots of the
embedded systems use a small subset of the language and at the
same time require as a norm some of the best optimization

OK, your company makes money with that kind of stuff. It is OK.

But maybe you acknowledge that there are OTHER companies that
make money in OTHER kinds of environments?

There are plenty of C user communities. Part of the tone in my post
comes from the limited representation that embedded systems has
at WG-14. In that sense I am typically one of a few people representing
embedded systems interests.

Why coudn't you propose a subset of C consisting of:

Standard language except the types

float, double, long double

and all associated stuff: math.h and stdio that use double,
complex, and tgmath.h, etc.

THAT would be a REAL progress, i.e. define a non-floating point
subset of C for micro-controllers and very small machines that
does not use floating point. The long long type would be optional,
with short 16, int 16 or 32, and long 32.

That is a feasible language where you can do a LOT of stuff.

That defines how most small embedded systems are implemented.
A compiler for small embedded systems compilers would be defined
as the core plus ISO/IEC 18037.

Why destroy the C99 standard?

I don't think it would destroy the C99 standard.

Yesterday I was looking at some of the WG14 papers that
led up to the release of C99 and it was clear that C89/C90
was a reference document of standard practice and the
discussions that led to C99 was dealing with everything
that was wrong with C as defined by C90.

The core language suggestions might want to look at these
papers that deal with C90 issues and not the extensions.

Regards,

w..