Downloadable standards file?

[Jim Cook]

I previously had asked if there was an online standards file so I could
read that and answer my own questions without posting here and getting
flamed for not having done my homework.

I was pointed to a file called n1124.pdf which turns out to be a C99
standard. It appears that quoting from that standard makes a lot of
people say "but C99 isn't widely supported, so C90 is what you ought to do."

Is there a C90 file I can download for free and cross reference with my
C99 one?

I have seen the FAQ 11.2 that says it's available for purchase. Given
that the C99/N1124.PDF appeared to be free from
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf, I was hoping
that there was at least a "good enough" C90 one also for free.

(Aside: if the consensus is to reject the new standard, why should one
be created? Do the people who say to use C90 really think it's better to
lock C forever to that? If my compiler is C99, shouldn't I be encouraged
to conform to that standard?)

 

[Guest]

I previously had asked if there was an online standards file so I could
read that and answer my own questions without posting here and getting
flamed for not having done my homework.

I was pointed to a file called n1124.pdf which turns out to be a C99
standard. It appears that quoting from that standard makes a lot of
people say "but C99 isn't widely supported, so C90 is what you ought to do."

Is there a C90 file I can download for free and cross reference with my
C99 one?

A quick search gives me

http://web.archive.org/web/20050207005628/http://dev.unicals.com/papers/c89-draft.html

as one possibility.

Note that n1124 is a post-C99 draft, not official C99. Similarly, there
is no official C90 freely available.

I have seen the FAQ 11.2 that says it's available for purchase. Given
that the C99/N1124.PDF appeared to be free from
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf, I was hoping
that there was at least a "good enough" C90 one also for free.

(Aside: if the consensus is to reject the new standard, why should one
be created? Do the people who say to use C90 really think it's better to
lock C forever to that? If my compiler is C99, shouldn't I be encouraged
to conform to that standard?)

It depends on how portable you want your code to be. Personally, I have
no problem with people using the common subset of C99 and what their
compiler supports. If anyone wants to compile that code with a
different compiler, and it rejects it because it doesn't support enough
of C99, it's the compiler that's at fault, not the code. Others prefer
to be able to compile their code on any platform with any conforming
compiler and write in the common subset of C90 and C99. What's best for
you is for you to decide.

 

[jacob navia]

Jim Cook a écrit :

I previously had asked if there was an online standards file so I could
read that and answer my own questions without posting here and getting
flamed for not having done my homework.

I was pointed to a file called n1124.pdf which turns out to be a C99
standard. It appears that quoting from that standard makes a lot of
people say "but C99 isn't widely supported, so C90 is what you ought to
do."

Is there a C90 file I can download for free and cross reference with my
C99 one?

I have seen the FAQ 11.2 that says it's available for purchase. Given
that the C99/N1124.PDF appeared to be free from
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf, I was hoping
that there was at least a "good enough" C90 one also for free.

(Aside: if the consensus is to reject the new standard, why should one
be created? Do the people who say to use C90 really think it's better to
lock C forever to that? If my compiler is C99, shouldn't I be encouraged
to conform to that standard?)

The people that told you that standard C is "rejected" here are speaking
for themselves. The current standard is C99, and that standard makes
older standards obsolete.

There is a group of people here that think that C should be as
backward looking as possible, they reject C99 want to come to 1989
and maybe even earlier.

Who cares?

The current standard is C99.

That document (n1124.pdf) is OK for personal use, but maybe you
should get the real standard (around 20 dollars) from ANSI,
or get the book "The C standard" (Wiley).

You can get it here:
http://www.amazon.com/Standard-Inco...=pd_bbs_1/103-0928102-5001447?ie=UTF8&s=books

That book is more expensive than the PDF of the standard from ANSI (48
dollars).

 

[osmium]

Jim Cook a écrit :

The people that told you that standard C is "rejected" here are speaking
for themselves. The current standard is C99, and that standard makes
older standards obsolete.

There is a group of people here that think that C should be as
backward looking as possible, they reject C99 want to come to 1989
and maybe even earlier.

Who cares?

The current standard is C99.

That document (n1124.pdf) is OK for personal use, but maybe you
should get the real standard (around 20 dollars) from ANSI,
or get the book "The C standard" (Wiley).

You can get it here:
http://www.amazon.com/Standard-Inco...=pd_bbs_1/103-0928102-5001447?ie=UTF8&s=books

That book is more expensive than the PDF of the standard from ANSI (48
dollars).

 

[Richard Tobin]

The people that told you that standard C is "rejected" here are
speaking for themselves. The current standard is C99, and that
standard makes older standards obsolete.

Surprisingly, ISO agrees:

This second edition cancels and replaces the first edition,
ISO/IEC9899:1990 [...]

So C90 is no longer an ISO standard, and therefore off-topic.

-- Richard

 

[Roland Pibinger]

The people that told you that standard C is "rejected" here are speaking
for themselves. The current standard is C99, and that standard makes
older standards obsolete.

Older standards are not 'obsolate' (whatever that exactly means).
Standards are not laws, they have no legislative power.

Who cares?
The current standard is C99.

The _latest_ C starndard is C99. I guess C90 is currently used by the
majority of C programmers.

Best regards,
Roland Pibinger

 

[Stephen Sprunk]

Older standards are not 'obsolate' (whatever that exactly means).
Standards are not laws, they have no legislative power.

Many ISO standards are enforced by laws in various jurisdictions. Not
the C one, thankfully, but many standards have a lot of de facto power
even when they doesn't have de jure power. For example, just try
connecting to the Internet without comforming to RFC 791.

The _latest_ C starndard is C99. I guess C90 is currently used by the
majority of C programmers.

Hogwash. The majority of C programmers use either Microsoft C or
GNU/POSIX C, not ISO C.

Intel couldn't even give away copies of ICC until they implemented all
the Microsoft and GNU extensions (and they're still having trouble,
since ICC produces code that deliberately performs worse on AMD CPUs).

S

 

[Keith Thompson]

The people that told you that standard C is "rejected" here are speaking
for themselves. The current standard is C99, and that standard makes
older standards obsolete.

There is a group of people here that think that C should be as
backward looking as possible, they reject C99 want to come to 1989
and maybe even earlier.

Who cares?

The current standard is C99.

[...]

Unfortunately, that's not realistic.

It is a fact that most C compilers implement the (officially obsolete)
C90 standard. It is also a fact, unfortunately, that most C compilers
do *not* yet fully implement the (now official) C99 standard.

I will note that jacob's own lcc-win32 compiler fails to implement
some features of C99. You can write conforming C99 code all you like,
but if you happen to use those features, lcc-win32 will reject it, as
will most other C compilers that you're likely to able to use. If you
want to write conforming C code as an academic exercise, feel free to
do so. If you happen to have one of the few implementations that
fully implements the C99 standard, and you're not concerned with
portability to other implementations, that's great. If you want to be
able to compile your code on as many systems as possible, I'm afraid
you're going to avoid those features of C99 that are not already in
C90.

Few, if any, posters here have said that the C language *should* be
restricted to the C90 standard. That is a distortion on jacob's part;
I can only assume that it's a deliberate one.

Many of us, myself included, have simply acknowledged the reality that
code that uses C99 features *is not portable*. Ignoring that fact is
foolish. I look forward eagerly to the day when all C implementations
(gcc, lcc-win32, Microsoft, etc.) fully support C99, but there is no
virtue in pretending that that day has already arrived. The only way
that's going to happen is if the *implementers* make it happen; as
programmers, there's not a whole lot we can do about it (other than
applying whatever pressure we can on the implementers).

Note that C99 is very nearly a superset of C90. If you write code in
the common subset of the two versions of the language (that basically
means writing conforming C90 code while avoiding the new C99
keywords), then you'll have code that is valid C99, and that any
future compiler, whether it conforms to C99 or not, will be able to
handle.

jacob, if you believe that C90 is "obsolete", why does your own
lcc-win32 compiler not fully support the current standard, seven years
after it was issued? I understand that it's a lot of work, and I'm
honestly not criticizing you for not having done it yet. But given
that fact, I'm bewildered by your insistence on ignoring C90.

C90 is *officially* obsolete, according to ISO. C99, and only C99, is
currently the *official* C standard, according to ISO. I truly wish
that those offical statements were better reflected in reality, but
they are not.

 

[Random832]

The people that told you that standard C is "rejected" here are
speaking for themselves. The current standard is C99, and that
standard makes older standards obsolete.

Surprisingly, ISO agrees:

This second edition cancels and replaces the first edition,
ISO/IEC9899:1990 [...]

So C90 is no longer an ISO standard, and therefore off-topic.

I thought the consensus was that all present and past C standards [and
with K&R1 counting as a standard] were on-topic.

 

[Random832]

Many ISO standards are enforced by laws in various jurisdictions. Not
the C one, thankfully, but many standards have a lot of de facto power
even when they doesn't have de jure power. For example, just try
connecting to the Internet without comforming to RFC 791.

In a lot of cases, some of it is a question of just _how_ non-conformant.

For example:
} Time to Live: 8 bits
} This field indicates the maximum time the datagram is allowed to
} remain in the internet system. If this field contains the value
} zero, then the datagram must be destroyed.

Now, if, say, I let every fifth packet through without decrementing it
or destroying it if it's reached zero, I'm not going to run into any
immediate problems in terms of getting booted off by machines, and it
may take a while for any humans to notice the problem.

Note that RFCs aren't generally standards. Now, as it happens, RFC 791
is also STD 5.

 

[Richard Heathfield]

jacob navia said:

The current standard is C99, and that standard makes
older standards obsolete.

If that is true, then your own implementation is obsolete, since it doesn't
conform to C99.

In practice, of course, C90 *is* the C Standard, no matter what ISO say, and
C99 is what will eventually replace it *only* if sufficient people can be
bothered to write conforming C99 implementations - which almost nobody has
seen fit to do, up to now.

 

[matevzb]

There is a group of people here that think that C should be as
backward looking as possible, they reject C99 want to come to 1989
and maybe even earlier.

Who cares?

The current standard is C99.

I really do care. First, I have yet to see a fully C99-compliant
compiler and second, there are a number of platforms on which this will
never happen. Since my code needs to run there as well (at least for
now), I'll stick to C90 (+ extensions) for as long as it's needed. From
my perspective, saying "Who cares?" implies pure ignorance.

 

[jacob navia]

matevzb a écrit :

I really do care. First, I have yet to see a fully C99-compliant
compiler and second, there are a number of platforms on which this will
never happen. Since my code needs to run there as well (at least for
now), I'll stick to C90 (+ extensions) for as long as it's needed. From
my perspective, saying "Who cares?" implies pure ignorance.

Excuse me but why I should care where YOUR code runs on?
If you do not want to use C99 it is your decision. I accept
that but the current standard is not C90, and as such there is
no point in trying to move backwards all the language because
of a possible problem with your code.

Which platform?
What problems did you encounter?

You do not specify...

 

[Richard Heathfield]

jacob navia said:

Excuse me but why I should care where YOUR code runs on?

No reason at all. That's the whole point of portability. It simply doesn't
matter where his code runs.

If you do not want to use C99 it is your decision.

Quite so. Even if he had a C99-conforming compiler, which is doubtful, it
appears that he'd rather use something that stands a chance of porting to
other platforms.

I accept
that but the current standard is not C90,

It's true that C90 is not the current de jure standard, but it remains the
current de facto standard for those who require portability.

and as such there is
no point in trying to move backwards all the language because
of a possible problem with your code.

Fine, so let's move the language forwards by getting some C99-conforming
implementations out there. There are way too few right now to make it a
viable standard.

Which platform?

Why should that matter? This is *C*, not Visual Basic.

 

[matevzb]

Excuse me but why I should care where YOUR code runs on? You shouldn't but I have to.
If you do not want to use C99 it is your decision.

It's not that I don't want to, it's that I can't.

Which platform?
What problems did you encounter?

You do not specify...

But you said you don't care.
<OT>It should run on HPUX, Windows, Solaris, Linux, Tru64, IRIX, Sinix,
AIX, Netware, SCO (OpenServer and UnixWare) to name the less
problematic ones. Then there are MPE/iX and OpenVMS (maybe AS/400 as
well). Note that gcc is only used for Linux (not my decision) and that
support for multiple versions of each system is required.</OT>

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:




No reason at all. That's the whole point of portability. It simply doesn't
matter where his code runs.




Quite so. Even if he had a C99-conforming compiler, which is doubtful, it
appears that he'd rather use something that stands a chance of porting to
other platforms.

So What?

Is this group called:

comp.std.portable

???

or maybe

comp.lang.portable

Look: I am not AGAINST portability, it is just
one of the variables that are useful in my work.

Another is easy of use, and yet another is efficiency.

When I write:

int fn(int Elements_Count)
{
double tab[Elements_Count];
}
This is easier FOR ME, than the other alternatives.

Why should I change my way of writing C programs because
some compiler doesn't implement this stuff?

Why should this group be obsessed with writing portable
programs? This is not the subject of this group but
the C language and the C standard as it is.

You do not like it?

Make a new group:

comp.lang.portable

where you discuss portability to all toasters of the world
where they run in the famous embedded processor that
doesn't use the bss -) or any other stuff for that
matter.

 

[jacob navia]

matevzb a écrit :

You shouldn't but I have to.


It's not that I don't want to, it's that I can't.


But you said you don't care.
<OT>It should run on HPUX, Windows, Solaris, Linux, Tru64, IRIX, Sinix,
AIX, Netware, SCO (OpenServer and UnixWare) to name the less
problematic ones. Then there are MPE/iX and OpenVMS (maybe AS/400 as
well). Note that gcc is only used for Linux (not my decision) and that
support for multiple versions of each system is required.</OT>

IBM Provides a C99 compiler for AIX. HPUX and TRUE64 use Compaq C, that
provides C99 support as they say in their web page.
SCO I do not know, but Windows you have many compilers with C99
support.


In any case I do not want to force you to use C99, but we are
discussing C here, not portability.

This NOT comp.lang.portable (as far as I see)

Yes, for your company portability is a must, so you must use
the smalles common denominator of all the compilers in all
the systems you support, and avoiding the BUGS in any version of all
of them.

Would you say then, "Do not use malloc"

Why?

Because the compiler in OSxxx version YYY has a bug in it.

OK. If you want to run in OSxxx and you have a cutomer with
version YYY of that system, and you must run there you do not
use malloc.

But why should that problem be a GENERAL RULE?

I mean I understand your problem, but please, you must understand
that in general, malloc runs, even if it is not portable because
the efficiency varies wildly from one implementation to the other,
and some of them are just awful or buggy...

 

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :

So What?

So that's why C90 remains useful to a great many C programmers.

Is this group called:

comp.std.portable

???

No, it's called comp.lang.c, and C90 is by far the most popular C standard
in existence, in terms of compiler support.

Why should I change my way of writing C programs because
some compiler doesn't implement this stuff?

No reason at all. C99 is topical here too.

Why should this group be obsessed with writing portable programs?

It isn't obsessed. It's concerned with portability. That is a valid and
sensible concern.

This is not the subject of this group but
the C language and the C standard as it is.

And the C Standard *is* C90. Yes, there's a new one out, but the real world
didn't catch up yet, with actual conforming compilers (except for a small
handful which almost nobody claims to use). In any event, K&R C remains
topical some 17 years after the ANSI C Standard was published, and C90
remains topical even though C99 has been out for 7 years. And when C0x is
ratified, C99 will still remain topical - and so will C90 and K&R C.

<snip>

 

[Richard Heathfield]

jacob navia said:

IBM Provides a C99 compiler for AIX. HPUX and TRUE64 use Compaq C, that
provides C99 support as they say in their web page.

But do they claim *conformance* to C99? If not, you don't know whether those
compilers will compile your C99 programs.

SCO I do not know, but Windows you have many compilers with C99
support.

Do those compilers claim *conformance* to C99? If not, you don't know
whether they'll compile your C99 programs.

<snip>

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:




But do they claim *conformance* to C99? If not, you don't know whether those
compilers will compile your C99 programs.




Do those compilers claim *conformance* to C99? If not, you don't know
whether they'll compile your C99 programs.

<snip>

Look, IBM says explicitely that they conform to the standard. Comeau
compiler
under windows says explicitely it conforms.

Of course you want a new standard that is implemented 100% everywhere.
That can't be, so you will always find something.

The situation is much worse in C++, where there was in a recent
survey by Plauger almost no compiler fully conforms.

Would you say then that programming in C++ is impossible?

And if some compiler has a bug, or a non-implemented stuff, so
what?

You call the maintenance and that was it.

And the compilers that DO conform to C90, do they always generate
100% verifieble CORRECT CODE? (What is even more important than
standards conformance)

No. They may have BUGS as many other stuff!

So what?

You call the maintenance! That's all.