Where to download C99 Standard

[Shivanand Kadwadkar]

I have been searching the C99 complete standard but i am not able to
get it on internet.

If anyone knows URL from where we can download please share it or
have a copy can you please send it to
me([email protected]) if you dont have any problem.

 

[Rich Webb]

I have been searching the C99 complete standard but i am not able to
get it on internet.

If anyone knows URL from where we can download please share it or
have a copy can you please send it to
me([email protected]) if you dont have any problem.

It's easy to find. Hop over to http://www.ansi.org and then use their
search box for "9899" for The Real Thing (tm). Or, look over at
http://www.iso-9899.info/wiki/The_Standard where in addition to the
official release versions you can also find links for drafts which
incorporate the base standard as a free download.

 

[John Bode]

I have been searching the C99 complete standard but i am not able to
get it on internet.

If anyone knows URL from where we can download  please share it or
have a copy can you please send it to
me([email protected]) if you dont have any problem.

A PDF of draft N1256 (C99 standard + technical correginda TC1, TC2,
and TC3) can be found at

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

AFAIK, this is the most up-to-date version available online (it is
officially a working paper, but should be good enough for most
purposes).

 

[tommy]

Shivanand Kadwadkar typed...

I have been searching the C99 complete standard but i am not able to get
it on internet.

If anyone knows URL from where we can download please share it or have
a copy can you please send it to me([email protected]) if
you dont have any problem.

if u do a search on bittorrent you can find a rar with ISO C90, ISO C99,
and Kernerghan & Ritchy all in one archive, nice

 

[Walter Banks]

if u do a search on . . . you can find a rar with ISO C90, ISO C99,
and Kernerghan & Ritchy all in one archive, nice

Violating copyrights is illegal and hurts everyone.

w..

 

[Keith Thompson]

I have been searching the C99 complete standard but i am not able to
get it on internet.

If anyone knows URL from where we can download please share it or
have a copy can you please send it to
me([email protected]) if you dont have any problem.

You cannot legally download the C99 standard itself without paying
for it. Searching iso.ch for 9899 indicates that they charge CHF
352.00 for a PDF copy of the C99 standard, which is exhorbitant.
ANSI changes either $349 or $30, depending on which (presumably
identical) version you want. (I paid $18 for my copy several years
ago; $30 isn't too bad.) You might also try your own national
standards body.

However, the latest *draft* is available at no charge at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.
This includes the C99 standard with the three Technical Corrigenda
merged into it; the changes are clearly marked with change bars, but
the original unmodified text is not included. (The TCs themselves
are available at no change from ansi.org.)

For most purposes, n1256.pdf is *more* useful than the actual
C99 standard.

There are also some preliminary drafts of the
upcoming C201X standard available. I think the latest is
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1516.pdf>, though
I could have missed a more recent one. This is interesting if you
want to see where the language is going in the future, but it has
no current official status, and you won't find implementations that
support the new features.

 

[Francois Grieu]

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

Francois Grieu

 

[jacob navia]

Le 29/12/10 13:55, Francois Grieu a écrit :

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

Francois Grieu

Microsoft decided that automatically allocated tables were
unnecessary.

int fn(int n)
{
in table[n];
}

This feature of C99 is now optional thanks to (who else
could have done that!) Plauger/Microsoft

 

[Keith Thompson]

Le 29/12/10 13:55, Francois Grieu a écrit :

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

See n1547 section 6.10.8.3, "Conditional feature macros".

Microsoft decided that automatically allocated tables were
unnecessary.

int fn(int n)
{
in table[n];
}

This feature of C99 is now optional thanks to (who else
could have done that!) Plauger/Microsoft

What makes you think Microsoft was responsible for this? I'm not
saying you're wrong, I'm just interested in seeing some hard
evidence. Microsoft apparently has (had?) no plans to support
even C99; I wonder why they'd have so much influence over C201X.

For those who don't want to download n1547.pdf, the list of conditional
feature macros is:

__STDC_ANALYZABLE__
The integer constant 1, intended to indicate conformance to
the specifications in annex L (Analyzability).

__STDC_IEC_559__
The integer constant 1, intended to indicate conformance
to the specifications in annex F (IEC 60559 floating-point
arithmetic).

__STDC_IEC_559_COMPLEX__
The integer constant 1, intended to indicate adherence to
the specifications in annex G (IEC 60559 compatible complex
arithmetic).

__STDC_LIB_EXT1__
The integer constant 201ymmL, intended to indicate support
for the extensions defined in annex K (Bounds-checking
interfaces).

__STDC_NO_COMPLEX__
The integer constant 1, intended to indicate that the
implementation does not support complex types or the
<complex.h> header.

__STDC_NO_THREADS__
The integer constant 1, intended to indicate that the
implementation does not support atomic types (including the
_Atomic type qualifier and the <stdatomic.h> header) or the
<threads.h> header.

__STDC_NO_VLA__
The integer constant 1, intended to indicate that the
implementation does not support variable length arrays or
variably modified types.

Of these, __STDC_NO_COMPLEX__ and __STDC_NO_VLA__ make existing
mandatory C99 features optional in C201X. Personally, I don't see
the point of either of these. They might save some relatively small
amount of work for implementers, but I don't see that they do any
good for programmers; neither feature should impose any significant
overhead on programs that don't use it.

 

[Francois Grieu]

On 29/12/10 13:55, Francois Grieu wrote:

See n1547 section 6.10.8.3, "Conditional feature macros". (..)

__STDC_ANALYZABLE__
The integer constant 1, intended to indicate conformance to
the specifications in annex L (Analyzability).

__STDC_IEC_559__
The integer constant 1, intended to indicate conformance
to the specifications in annex F (IEC 60559 floating-point
arithmetic).

__STDC_IEC_559_COMPLEX__
The integer constant 1, intended to indicate adherence to
the specifications in annex G (IEC 60559 compatible complex
arithmetic).

__STDC_LIB_EXT1__
The integer constant 201ymmL, intended to indicate support
for the extensions defined in annex K (Bounds-checking
interfaces).

__STDC_NO_COMPLEX__
The integer constant 1, intended to indicate that the
implementation does not support complex types or the
<complex.h> header.

__STDC_NO_THREADS__
The integer constant 1, intended to indicate that the
implementation does not support atomic types (including the
_Atomic type qualifier and the <stdatomic.h> header) or the
<threads.h> header.

__STDC_NO_VLA__
The integer constant 1, intended to indicate that the
implementation does not support variable length arrays or
variably modified types.

Of these, __STDC_NO_COMPLEX__ and __STDC_NO_VLA__ make existing
mandatory C99 features optional in C201X. Personally, I don't see
the point of either of these. They might save some relatively small
amount of work for implementers, but I don't see that they do any
good for programmers; neither feature should impose any significant
overhead on programs that don't use it.

Useful info. Thanks,

Francois Grieu

 

[Chris H]

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

Francois Grieu

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.

 

[Keith Thompson]

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.

Speaking only for myself, I was skeptical of your claims because I
saw no independent evidence of them. Given the relative (but not
complete) openness of the process, I would have expected to see
some indication of such a radical change. (And again, if I recall
correctly, what you were claiming would have been much more radical
than what we're actually seeing in n1547.)

Drifting a bit, why are VLAs and complex arithmetic the only
two C99 features that are being made optional? Does this really
significantly reduce the burden on implementers? Are there any
existing implementations that (a) implement a substantial portion of
the features defined by C99 and not by C90, but (b) don't implement
both VLAs and complex arithmetic?

 

[jacob navia]

Le 30/12/10 20:02, Keith Thompson a écrit :

Drifting a bit, why are VLAs and complex arithmetic the only
two C99 features that are being made optional?

Because Microsoft vetoed them. They aren't in C++ and any
independent development of a dead language like C is
a bad idea according to Microsoft.

Does this really
significantly reduce the burden on implementers?

Not at all.

Are there any
existing implementations that (a) implement a substantial portion of
the features defined by C99 and not by C90, but (b) don't implement
both VLAs and complex arithmetic?

VLAs can be easily implemented using alloca...

C++ doesn't have this feature, and Microsoft (Plauger) objected.

This individual (Plauger) was the most ardent defender of leaving
asctime() with its buffer overflow, and has been a negative force
in the development of anything useful in standard C for years.

Yes, he wrote a C library ages ago. Now, he writes C++ libraries
mainly for its big client, Microsoft, and it is the main force behind
an absolute conservatism in the C standards committee.

At least that is the iumpression that I have after discussing the
asctime() issue in comp.lang.c with him.

In the last time he resigned from the C++ standards "steering" group
(or similar if my memory serves). It is a pity that he stayed in the
C standards committee, and proposed to dismantle several features
of C99, a proposal that was accepted.

 

[Seebs]

Drifting a bit, why are VLAs and complex arithmetic the only
two C99 features that are being made optional? Does this really
significantly reduce the burden on implementers? Are there any
existing implementations that (a) implement a substantial portion of
the features defined by C99 and not by C90, but (b) don't implement
both VLAs and complex arithmetic?

I think the more interesting question would be, are there implementations
that didn't bother to implement much of C99 *because* they didn't want
to implement VLAs and/or complex arithmetic?

-s

 

[jacob navia]

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

I think the more interesting question would be, are there implementations
that didn't bother to implement much of C99 *because* they didn't want
to implement VLAs and/or complex arithmetic?

-s

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

 

[Keith Thompson]

Le 30/12/10 20:02, Keith Thompson a écrit :

Because Microsoft vetoed them. They aren't in C++ and any
independent development of a dead language like C is
a bad idea according to Microsoft.

Please provide concrete evidence that Microsoft vetoed these
features. (Note that they're still in the language; they're merely
optional.)

Not at all.


VLAs can be easily implemented using alloca...

Not really. Space allocated by alloca() is deallocated on return
from the calling function. VLAs have automatic storage duration,
and are deallocated on exit from the nearest enclosing block.
(I hope lcc-win doesn't use alloca() to implement VLAs.)

C++ doesn't have this feature, and Microsoft (Plauger) objected.

P.J. Plauger is not, and never has been, an employee of Microsoft.
If you're saying that Plauger objected for reasons having to do
with Microsoft, that may be true (can someone else comment?),
but your statement implies more than that.

This individual (Plauger) was the most ardent defender of leaving
asctime() with its buffer overflow, and has been a negative force
in the development of anything useful in standard C for years.

Yes, he wrote a C library ages ago. Now, he writes C++ libraries
mainly for its big client, Microsoft, and it is the main force behind
an absolute conservatism in the C standards committee.

At least that is the iumpression that I have after discussing the
asctime() issue in comp.lang.c with him.

Citation, please?

In the last time he resigned from the C++ standards "steering" group
(or similar if my memory serves). It is a pity that he stayed in the
C standards committee, and proposed to dismantle several features
of C99, a proposal that was accepted.

As of the latest draft, two C99 features (is that "several"?) are being
made optional, not "dismantled".

Can someone please answer my original question (about the rationale
for making VLAs and complex types optional in C201X) *without*
engaging in personal attacks?

 

[Keith Thompson]

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

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

Can you provide independent evidence for this claim?

 

[Chris H]

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.

Speaking only for myself, I was skeptical of your claims because I
saw no independent evidence of them. Given the relative (but not
complete) openness of the process, I would have expected to see
some indication of such a radical change. (And again, if I recall
correctly, what you were claiming would have been much more radical
than what we're actually seeing in n1547.)

Not everything is written down in the documents.

Drifting a bit, why are VLAs and complex arithmetic the only
two C99 features that are being made optional? Does this really
significantly reduce the burden on implementers?

Probably not because most implementers did not bother with them

Are there any
existing implementations that (a) implement a substantial portion of
the features defined by C99 and not by C90, but (b) don't implement
both VLAs and complex arithmetic?

Not sure, C99 implementation is very patchy

 

[Chris H]

Le 30/12/10 20:02, Keith Thompson a écrit :
Yes, he wrote a C library ages ago. Now, he writes C++ libraries
mainly for its big client, Microsoft,

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

and it is the main force behind
an absolute conservatism in the C standards committee.

The embedded community is generally conservative.

In the last time he resigned from the C++ standards "steering" group
(or similar if my memory serves). It is a pity that he stayed in the
C standards committee, and proposed to dismantle several features
of C99, a proposal that was accepted.

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

 

[Chris H]

lock.
(I hope lcc-win doesn't use alloca() to implement VLAs.)


P.J. Plauger is not, and never has been, an employee of Microsoft.
If you're saying that Plauger objected for reasons having to do
with Microsoft, that may be true (can someone else comment?),
but your statement implies more than that.

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.

ISO-C++ Working Group. WG21

As of the latest draft, two C99 features (is that "several"?) are being
made optional, not "dismantled".

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*