Where to download C99 Standard

[Chris H]

Le 30/12/10 20:21, Seebs a écrit :

One: Microsoft corp. That is why they are optional now.

And most of the compilers in the embedded sector?

This time it is not a conspiracy by the Great Satan M$ or at least not
by them alone. If the majority of PJP's customers wanted VLA's (or green
cheese even) that is what they would get. The truth is the industry
does not really want them.

 

[Chris H]

Can you provide independent evidence for this claim?

Iven if it were true you are never going to see something like this in
writing. It would get discussed in coffee breaks at WG meetings as many
things are.

 

[James Kuyper]

In message<[email protected]>, Francois Grieu
On 28/12/2010 23:16, Keith Thompson wrote:
There are also some preliminary drafts of the
upcoming C201X standard available. I think the latest is
[n1516] though I could have missed a more recent one.

Latest seems to be n1547, made 2010-12-02, posted 2010-12-03
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1547.pdf>

I wonder what are the C99 features made non-mandatory in C201x,
as hinted by "Major changes from the previous edition include:
— conditional (optional) features (including some that were
previously mandatory)"

For several years I have been saying that some C99 features would be
dropped in the next standard and no one believed me. It all stemmed
from the discussions at the end of the WG14 meeting in April 2007.

I see some features being made optional. I don't see anything
being dropped.

Semantics. If features no one is implementing are being made optional
they are effectively dropped.

True. For instance, if I have to write portable code working with
complex numbers, I cannot afford to assume that complex support will
ever be universally available. That's not a change, of course; fully
conforming C99 compilers are still quite rare, and with this decision, I
doubt that many more will bother adding complex support in the future;
in fact, I expect that many will drop whatever support they currently
provide.

With C1x, I could, in principle, do a feature-test #if to determine if
complex numbers are supported, and if so, write simple, easily
understood code using them directly. However, in the #else clause, I'll
have to write substantially more complicated code that does the same
thing without relying upon complex support, storing the real and complex
components as separate members of the same array, or as separate members
of a struct.

Since I'll have to write the complicated code anyway, why bother writing
the simpler code? Making sure that the more complicated code is correct
is going to be difficult enough; why add in the need to make sure that
the simple code and the complicated code say the same thing? Therefore,
as far as portable code is concerned, making it optional is pretty much
the same as dropping it entirely. Using some other language with
guaranteed support for complex numbers, such as C++ or Fortran, would be
the more appropriate way to go, I think.

All this means is that the C committee has decided to restrict the
domain of usefulness of C, in the interests of making is cleaner, easier
to understand language and standard library. That might be a very
reasonable decision for the language as a whole, no matter how
inconvenient it may be for those who rely upon complex support. However,
the full benefits of that decision won't be gained until complex support
is actually dropped, and not merely optional, because until that's done,
it won't actually be a simpler language and standard library.

 

[robertwessel2]

In message<[email protected]>, Francois Grieu
On 28/12/2010 23:16, Keith Thompson wrote:
There are also some preliminary drafts of the
upcoming C201X standard available.  I think the latest is
[n1516] though I could have missed a more recent one.
Latest seems to be n1547, made 2010-12-02, posted 2010-12-03
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1547.pdf>
I wonder what are the C99 features made non-mandatory in C201x,
as hinted by "Major changes from the previous edition include:
— conditional (optional) features (including some that were
  previously mandatory)"
For several years I have been saying that some C99 features would be
dropped in the next standard and no one believed me.   It all stemmed
from the discussions at the end  of the WG14 meeting in April 2007.
I see some features being made optional.  I don't see anything
being dropped.

Semantics. If features no one is implementing are being made optional
they are effectively dropped.

True. For instance, if I have to write portable code working with
complex numbers, I cannot afford to assume that complex support will
ever be universally available. That's not a change, of course; fully
conforming C99 compilers are still quite rare, and with this decision, I
doubt that many more will bother adding complex support in the future;
in fact, I expect that many will drop whatever support they currently
provide.

With C1x, I could, in principle, do a feature-test #if to determine if
complex numbers are supported, and if so, write simple, easily
understood code using them directly. However, in the #else clause, I'll
have to write substantially more complicated code that does the same
thing without relying upon complex support, storing the real and complex
components as separate members of the same array, or as separate members
of a struct.

Since I'll have to write the complicated code anyway, why bother writing
the simpler code? Making sure that the more complicated code is correct
is going to be difficult enough; why add in the need to make sure that
the simple code and the complicated code say the same thing? Therefore,
as far as portable code is concerned, making it optional is pretty much
the same as dropping it entirely. Using some other language with
guaranteed support for complex numbers, such as C++ or Fortran, would be
the more appropriate way to go, I think.

All this means is that the C committee has decided to restrict the
domain of usefulness of C, in the interests of making is cleaner, easier
to understand language and standard library. That might be a very
reasonable decision for the language as a whole, no matter how
inconvenient it may be for those who rely upon complex support. However,
the full benefits of that decision won't be gained until complex support
is actually dropped, and not merely optional, because until that's done,
it won't actually be a simpler language and standard library.

Remember too that complex support was never required for freestanding
implementations in C99.

But it's always baffled me. I can sort-of see a justification for the
opposition to VLAs in that they require some significant changes in an
implementation, and can be particularly clumsy on certain small
implantations, but I just can't fathom the resistance to for complex.
While it does add some new types, and the associated conversion rules,
that should be a pretty small change. The generated code is trivial
too, once you have float. The library does present some complexities,
but none really worse that those for the touchier items in the float
library. And as for excessive bulk on small implementations, many of
those make float optional under the hood already (IOW, you have to
compile your program with the "-hasfloat" flag if you actually want to
use float), there's no reason not to expect vendors for those platform
to have any trouble doing the same for complex.

I don’t object to optional features in a language, but I’d expect them
more in something like TCP/IP or threading libraries. At least we’re
getting one of those.

 

[Ben Pfaff]

Seriously! Sockets & PThreads are de facto standards anyway - why not
take the next step and formalize them?

They are already standardized, as part of POSIX.

 

[Keith Thompson]

In message <[email protected]>, Francois Grieu
On 28/12/2010 23:16, Keith Thompson wrote:
There are also some preliminary drafts of the
upcoming C201X standard available. I think the latest is
[n1516] though I could have missed a more recent one.

Latest seems to be n1547, made 2010-12-02, posted 2010-12-03
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1547.pdf>

I wonder what are the C99 features made non-mandatory in C201x,
as hinted by "Major changes from the previous edition include:
— conditional (optional) features (including some that were
previously mandatory)"

For several years I have been saying that some C99 features would be
dropped in the next standard and no one believed me. It all stemmed
from the discussions at the end of the WG14 meeting in April 2007.

I see some features being made optional. I don't see anything
being dropped.

Semantics.

I'm not sure that dismissing "semantics" is appropriate in a
discussion of language standards. }

If features no one is implementing are being made optional
they are effectively dropped.

gcc implements both complex numbers and VLAs; other compilers do
as well. I don't think there would be any reason for existing
compilers to drop support for them.

If you want to restrict the discussion to embedded systems,
<complex.h> isn't required for freestanding implementations (though
support for complex arithmetic still is).

I wouldn't think that VLA support would require much effort on the
part of compiler writers, nor should it impose a cost on code that
doesn't use them.

Not everything is written down in the documents.

True, but I didn't hear anything about this from anyone else on the
committee.

Probably not because most implementers did not bother with them


Not sure, C99 implementation is very patchy

So that's still an open question.

 

[Keith Thompson]

There are other big clients... not all the world is a PC.


The embedded community is generally conservative.



SO I was not the only one saying bits of C99 should be dropped....

Just to avoid confusion, the above contains nothing that I wrote.

 

[Keith Thompson]

As you say PJP is NOT an employee of MS. Whilst MS are a big customer of
his so are most of the other high end compiler companies. Most of the
others are in the embedded space and they are still on C90 (actually
C95) and they want a compact C language that runs on MCU from 8-128
bits. It is the 8 (and some 16) bit systems where they need to keep the
language compact.

BTW there are stil more 8 bit MCU used than the 16 and 31 bit MCU put
together.

So why not keep VLAs and complex arithmetic mandatory for hosted
implementations?

[...]

 

[Keith Thompson]

Iven if it were true you are never going to see something like this in
writing. It would get discussed in coffee breaks at WG meetings as many
things are.

Yes, coffee breaks at WG meetings that jacob did not attend.

jacob, what is the basis for your claim that Microsoft was behind making
VLAs and complex arithmetic optional? Do you have inside information?

 

[Keith Thompson]

If you want to restrict the discussion to embedded systems,
<complex.h> isn't required for freestanding implementations (though
support for complex arithmetic still is).

[...]

My mistake, in C99 freestanding implementations are not required
to support complex types at all (C99 4p6).

Which reinforces my question: if the pressure to make complex types
optional is based on the needs of embedded systems, what would be
the harm of maintaining the status quo, leaving them mandatory for
hosted implementations and optional for freestanding implementations?

For C201X, VLAs could also be made optional for freestanding
implementations (with the feature macro from the latest draft)
and mandatory for hosted implementations.

Are there any *hosted* C99-ish implementations that don't support
complex types and VLAs? Have any implementers chosen not to
implement C99 because of these features?

 

[Seebs]

Because the majority of the industry does not want/need them. There are
a lot of problems in C99. They are trying fix them for C1*

I am torn on VLAs. I quite like them, and I think I even use them in a few
places, but they have serious suitability problems for some targets.

-s

 

[Chris H]

So why not keep VLAs and complex arithmetic mandatory for hosted
implementations?

What has hosted got to do with it? You can run an RTOS on 8 and 16 bit
systems and people do.

 

[Chris H]

Yes, coffee breaks at WG meetings that jacob did not attend.

There is as with any committee a LOT more going on than just the things
that appear in the published documents. A Lot happens in discussions
and verbal exchanges.

jacob, what is the basis for your claim that Microsoft was behind making
VLAs and complex arithmetic optional? Do you have inside information?

MS DID have an influence. Why not they are a major compiler company and
are probably the largest single SW on the planet (in terms of people
using their tools, OS and apps). However they do not control anything
and other compiler companies, library companies etc also have input as
to other organisations and individuals. It is a very diverse group and
no one can or does control the ISO C panel which incidentally is made
up of representatives of National Bodies.

Each National Body is in itself a committee. I was Convenor of the UK C
panel for 4 years. The NB selects a Hod (Head of Delegation) and a
Principle Expert ( In the UK it was the Principal Expert for the UK or
PEUK.... try pronouncing it

So it is very difficult for any single company to drive the ISO WG.

The closest we came to this was IBM who put people on to (I think) half
a dozen National Bodies in order to explain their Decimal Maths
proposals. In the UK we had several world class experts who interrogated
the IBM rep also a highly respected expert to ensure the proposals were
solid. Then we took a position on it as did every other country then
the National Bodies went to the ISO WG and voted.

SO M$ can not just push things through.

 

[jacob navia]

Le 31/12/10 23:00, Keith Thompson a écrit :

Yes, coffee breaks at WG meetings that jacob did not attend.

jacob, what is the basis for your claim that Microsoft was behind making
VLAs and complex arithmetic optional? Do you have inside information?

Plauger would never do anything that his principal client would not
approve. This is just plain to anyone.

I have nothing against microsoft as a company since I developed for
years for their products, but they contributed to the problems
of the c99 standard by boycotting it. They have dropped almost
completely any official C support, and stayed at c89 in their
compilers, ignoring even "long long" and stickying to their
__int64 nomenclature for years.

 

[Nick]

I am torn on VLAs. I quite like them, and I think I even use them in a few
places, but they have serious suitability problems for some targets.

The real pain with them becoming optional is that they aren't something
that it's easy to conditionally do - unlike a missing function.
Particuarly as the natural fallback on many (most?) implementations is
the non-standard alloca.

So you end up with:
first preference: char workspace[strlen(input)]
second preference: char *workspace = alloca(strlen(input);
third preference: char *workspace = malloc(strlen(input));
...
free(workspace);
and that's before you deal with error checking and alloca having
function lifetype which VLAs (and, if you want, the malloc/free pair)
are block based.

You're going to have so many #if/else/endif around there that the code
is going to be unreadable. Or you use malloc all the time which is
inefficient to say the least in a frequently called function.

 

[Seebs]

What has hosted got to do with it? You can run an RTOS on 8 and 16 bit
systems and people do.

So? The conventional boundary has been that features which some people
think are "too expensive" but which are sufficiently valuable to include
in general end up being required in a hosted environment but optional
in a freestanding environment. Note that running an RTOS doesn't necessarily
imply that you're in a hosted environment. Heck, at one point Microsoft
Windows was officially a freestanding environment, as I recall.

-s

 

[Keith Thompson]

Le 31/12/10 23:00, Keith Thompson a écrit :

Plauger would never do anything that his principal client would not
approve. This is just plain to anyone.

No, it is not.

Do you know Plauger personally? Did you attend the meetings at
which these changes were discussed?

I am asking *you*, jacob, what basis you have for the claims
you're making. If you're merely speculating on the basis of who
P.J. Plauger's clients happen to be, I'm frankly not interested.
If you have actual information rather than speculation, I invite
you to share it with us.

I have nothing against microsoft as a company since I developed for
years for their products, but they contributed to the problems
of the c99 standard by boycotting it. They have dropped almost
completely any official C support, and stayed at c89 in their
compilers, ignoring even "long long" and stickying to their
__int64 nomenclature for years.

Then why would they care what happens to C201X? If C201X removes or
makes optional enough of the C99 features they don't like, do they
intend to support C201X? More important, *have they said so*, or
are you just speculating?

 

[Seebs]

No, it is not.

Do you know Plauger personally? Did you attend the meetings at
which these changes were discussed?

FWIW, I've met Plauger, and read a fair bit of his writing, and I don't
believe that for a minute.

Jacob... What is the deal here? You are constantly inferring attacks
where none are visible to other people, you seem to think everyone is
dishonest... Have you considered seeing a qualified professional about
this apparently very severe depression? It's screwing up your life and
social interactions. Get it dealt with. You are much smarter than this.

-s

 

[jacob navia]

Le 01/01/11 23:44, Keith Thompson a écrit :

No, it is not.

Do you know Plauger personally? Did you attend the meetings at
which these changes were discussed?

Just don't care neither about plauger nor about you.

I am asking *you*, jacob, what basis you have for the claims
you're making. If you're merely speculating on the basis of who
P.J. Plauger's clients happen to be, I'm frankly not interested.
If you have actual information rather than speculation, I invite
you to share it with us.

It is a fact that Plauger presented the key propositions of
taking out essential parts of C99. In fact, as has been
discussed elsewhere in this thread, this eliminates the C99
standard since nobody will develop to implement a standard
that is being dropped by its own standards committee.

C is, as a matter of fact, rewound to the level of C89 until
xxxx years from now when the new standard is eventually
approved. Then, implementors will think twice if it is worth
to implement a standard that can be at any time dropped
by its own standards body.

All this are the CONSEQUENCES of Plauger proposal. And this are
facts, Mr Thompson that you will never acknowledge of course.

I have worked for almost a decade in implementing C99 and
the fact that after all this discussions I see mr Hills

"I TOLD YOU I TOLD YOU"

and all those people in this group (you and heathfield as principal
proponents) that fought AGAINST C99 be given reason by the
standards committee is just too much.

In this group there are the ones that pontificate (like you, without
ever propsoing anything formal into the standards body,
or just "warn against portability problems of C99) etc,
and the stupids like me that work for years constructing stuff,
developing programs, distributing them at personal expense
for free (to be treated of "shrewd software vendors") and at the end
see their work destroyed and realize, yes, I have worked for nothing.

You have won, together with that individual "seebs" that counsels
me to have some medication or treatment because I accuse
people of... what actually?

Will you (and seebs) deny that Plauger proposed to make many parts of
C99 optional?

Why do I have to give any PROOF?

Proof of WHAT?

It is a known fact that Plauger proposed that and that the committee
approved it.

I have been describing the consequences.

And I am fed up with this. Neither you nor seebs are worth more wasting
of time.

 

[jacob navia]

Le 01/01/11 23:49, Seebs a écrit :

FWIW, I've met Plauger, and read a fair bit of his writing, and I don't
believe that for a minute.

Jacob... What is the deal here? You are constantly inferring attacks
where none are visible to other people, you seem to think everyone is
dishonest... Have you considered seeing a qualified professional about
this apparently very severe depression? It's screwing up your life and
social interactions. Get it dealt with. You are much smarter than this.

-s

Yes, you are right

I went to a professional and I explained my situation.

He told me:

"Look jacob, just do not speak with assholes"

I am sorry, I forgot his advice