So what Standard are we working off?

[Frederick Gotham]

If we look at a programming language such as C++: When an updated Standard
comes out, everyone adopts it and abandons the previous one.

It seems though that things aren't so clear-cut in the C community. It
would seem that C99 is the most up-to-date Standard, but far more people
seem to be working off the C89 Standard.

Could someone please explain to me why this is so?

 

[Sjouke Burry]

If we look at a programming language such as C++: When an updated Standard
comes out, everyone adopts it and abandons the previous one.

It seems though that things aren't so clear-cut in the C community. It
would seem that C99 is the most up-to-date Standard, but far more people
seem to be working off the C89 Standard.

Could someone please explain to me why this is so?

Because the old one works fine?
(Or,dont repair something that is not broken).

 

[santosh]

If we look at a programming language such as C++: When an updated Standard
comes out, everyone adopts it and abandons the previous one.

It seems though that things aren't so clear-cut in the C community. It
would seem that C99 is the most up-to-date Standard, but far more people
seem to be working off the C89 Standard.

Could someone please explain to me why this is so?

Because C99 has not been widely and completely implemented yet, and
because, for most programs, C89 works fine.

 

[Keith Thompson]

If we look at a programming language such as C++: When an updated Standard
comes out, everyone adopts it and abandons the previous one.

It seems though that things aren't so clear-cut in the C community. It
would seem that C99 is the most up-to-date Standard, but far more people
seem to be working off the C89 Standard.

Could someone please explain to me why this is so?

Before the C89 standard was published, the C programming community was
in a major mess. K&R1 was the closest thing to a standard, but it
wasn't enough to guarantee consistency. Different compiler vendors
implemented their own incompatible extensions, and it was very
difficult to write portable code. People waited eagerly for the ANSI
standard to appear, and vendors started implementing parts of it
before it was published.

It made the difference between not having a standard and having a
standard.

When the 1999 updated standard was issued, there was already an
existing standard that had been nearly universally adopted. It wasn't
perfect, but it did make it possible to write actual portable code.
There wasn't nearly as much demand for C99 as the was for C89; it made
the difference between having one standard and having another
different standard.

Historcial note: The C89 standard was issued by ANSI in 1989. It was
re-issued by ISO with cosmetic changes (such as section numbering
changes) in 1990; the ISO standard was then adopted by ANSI. Because
of this, I prefer to refer to it as C90 rather than C89, and as ISO C
rather than ANSI C. (ANSI C89 and ISO C90 are the same language,
described by slightly different standard documents.)

ANSI, as a member body of ISO, has adopted the 1999 ISO C standard, so
strictly speaking "ANSI C" should refer to C99, but it usually refers
to C89 or C90.

There was also a minor update in 1995.

 

[pete]

If we look at a programming language such as C++:
When an updated Standard
comes out, everyone adopts it and abandons the previous one.

It seems though that things aren't so clear-cut in the C community. It
would seem that C99 is the most up-to-date Standard,
but far more people
seem to be working off the C89 Standard.

Could someone please explain to me why this is so?

C89 is generally considered to be
a great improvement over K&R C, in every way.
K&R C is still on topic here, but you should always make it clear
that you are discussing K&R C, if that's the case.

C99 has some nice features.
What seems to be common these days, are C89 implementations
with some C99 features as extensions.

Some C99 features are considered by some,
to be pointless introductions of complexity
into a language that had a relatively simple definition
as one of its most attractive characteristics.

ISO/IEC 9899: 1990, is 227 pages.
ISO/IEC 9899:1999 (E), is 554 pages.

 

[Frederick Gotham]

Keith Thompson posted:

When the 1999 updated standard was issued, there was already an
existing standard that had been nearly universally adopted. It wasn't
perfect, but it did make it possible to write actual portable code.
There wasn't nearly as much demand for C99 as the was for C89; it made
the difference between having one standard and having another
different standard.

Do you think the C99 Standard will ever replace the C90 Standard, or do you
think the C community is content with C90 and does not want to change
anything?

Is there anything particularly unpleasant about C99? When I first started
to realise that everyone was using C90, my first presumption about the
situation was that there was some horrible feature about C99 which nobody
liked (VLA's maybe?)?

Are there ever times when you're programming in C that you would like to
use a C99 feature that isn't present in C90?

 

[Frederick Gotham]

pete posted:

Some C99 features are considered by some,
to be pointless introductions of complexity
into a language that had a relatively simple definition
as one of its most attractive characteristics.

ISO/IEC 9899: 1990, is 227 pages.
ISO/IEC 9899:1999 (E), is 554 pages.

What such features do you think add needless complexity?

I myself am not crazy about VLA's. (Even in C++, we like to be explicit
about using dynamic memory allocation, be it by using "malloc" or "operator
new").

 

[Ben Pfaff]

ISO/IEC 9899: 1990, is 227 pages.
ISO/IEC 9899:1999 (E), is 554 pages.

That's partly because the font size was increased.

 

[pete]

pete posted:


What such features do you think add needless complexity?

<stdbool.h>

I'm sure there must be something else in a language
definition that's more than twice the size of C89,
but I don't have it at the forefront of my mind.

Maybe it's just that I know most of the C89 standard by now,
and the task of learning C99 makes me feel like Sisyphus.

I myself am not crazy about VLA's.

That's another one.
It complicates the relationship between
sizeof and constant expressions.

 

[pete]

That's partly because the font size was increased.

I hadn't realised that.

But now that you mention it,
the text of C89 looks to be about the same
as the footnotes of C99.

 

[Keith Thompson]

<stdbool.h>

Really? I *like* <stdbool.h>; my only complaint is that "bool",
"false", and "true" weren't built into the language in the first
place.

I mention this not to argue this particular point, but to illustrate
that for *any* feature, some people are going to like it and some
people are going to hate it.

[...]

That's another one.
It complicates the relationship between
sizeof and constant expressions.

I don't mind the way it complicates sizeof (after all, there's no
effect unless you actually use sizeof on a VLA). My problem with VLAs
is that they let you allocate an arbitrary amount of memory during
execution with no mechanism for detecting or handling an allocation
error. Of course old-style arrays do the same thing, but VLAs somehow
feel more dangerous because the allocation size is determined during
execution.

 

[Peter Nilsson]

Keith Thompson posted:

Do you think the C99 Standard will ever replace the C90 Standard,

It already has. Note that most regulars in clc actually quote c&v from
the
C99 standard because their copies of the C90 standard have long since
gone and for the most part, the semantics are unchanged.

or do you think the C community is content with C90 and does not want to
change anything?

Define the C community. [Comp.lang.c is far from representative of the
wider
C community. Of course, it's not supposed to be!]

Note that the C committee itself consists almost entirely of people
willing to
shell out the clams to personally invest in changes to the C language.
Many
of them are major vendours with a considerable stake in the C language.

You seem to also be missing the fact that the most useful features of
C99 are already implemented as extensions on many C90 implementations.
C99 largely went about standardising the more common and useful
extensions.

One of the biggest change to C99 was IEEE support. Support which will
no doubt be adopted by C++ (along with many other C99 features.) The
future changes to C++ will no doubt influence more C vendours to update
their C implementations (typically shipped with C++ implementations.)

There is also considerable work being done as adjuncts to C, not
necessarily the C standard itself.

Is there anything particularly unpleasant about C99?

Only those that were unpleasant in C90 and remain in C99! ;-)

When I first started to realise that everyone was using C90, my first
presumption about the situation was that there was some horrible
feature about C99 which nobody liked (VLA's maybe?)?

Are there ever times when you're programming in C that you would like
to use a C99 feature that isn't present in C90?

Yes. But as I said, the features are quite often already present in
C90 compilers as extensions. So a lot of code that uses the
extensions will need little modification when C99 compilers become
more prevalent.

 

[Rouben Rostamian]

Are there ever times when you're programming in C that you would like to
use a C99 feature that isn't present in C90?

As others have noted, features deemed desirable vary from user to user.

But since you asked, here are my personal C99 favorites:

o complex type
o snprintf
o local loop indices, as in: for (int i=0; i<n; i++)
o __VA_ARG__ for preprocessor macros
o __func__ for function names

 

[Ben Pfaff]

It already has. Note that most regulars in clc actually quote
c&v from the C99 standard because their copies of the C90
standard have long since gone and for the most part, the
semantics are unchanged.

The reason that I quote mainly from C99 is because the final
standard is available as a nicely generated PDF (which I have
converted to plain text format). The older standard was only
available in draft form in an easy-to-cut-and-paste format
(although a PDF was available, it was, as I understand it, a
scanned version of the dead trees).

I can't speak for the other regulars, of course.

 

[Keith Thompson]

The reason that I quote mainly from C99 is because the final
standard is available as a nicely generated PDF (which I have
converted to plain text format). The older standard was only
available in draft form in an easy-to-cut-and-paste format
(although a PDF was available, it was, as I understand it, a
scanned version of the dead trees).

I can't speak for the other regulars, of course.

I have a PDF copy of the final C90 standard, and yes, it appears to be
scanned from dead trees, and it has no PDF bookmarks. I can
copy-and-paste from it, but the result looks like this:

4 Compliance

A srr-icr!\ corlfornri~~ PWJXI?U~~ shall use only those features
of the language and library specified in this International
Standard It shall not produce output dependent on any unspecitied.
undefined. or implementation-detined behavior. and shall not
exceed any minimum implementation limit

Actually it's not usually that bad (there seems to be a problem with
italics), but I do get a lot of errors involving characters that look
similar (',' vs. ',', 't' vs 'f', etc.). I usually clean things up
when I post them here. (Actually, I usually copy-and-paste from n1124
instead.)

 

[lovecreatesbeauty]

Really? I *like* <stdbool.h>; my only complaint is that "bool",
"false", and "true" weren't built into the language in the first
place.

typedef int32 bool_t;
#define true 1
#define false 0

This works fine, why bother to add three keywords and modify the
language.

My problem with VLAs
is that they let you allocate an arbitrary amount of memory during
execution with no mechanism for detecting or handling an allocation
error.

The language (with the revised standard) manages it and guarantees the
memory allocation for VLAs, normal arrays, ints and doubles. It is
promising it, right?

Do you worry if this fails: Char arr[999999];

lovecreatesbeauty

 

[santosh]

typedef int32 bool_t;
#define true 1
#define false 0

This works fine, why bother to add three keywords and modify the
language.

You've done the same above with the additional disadvantage that each
programmer might give his own name to these types, resulting in
confusion. On the other hand, if everyone uses the standard keywords,
code is more readable.

Besides, you shouldn't really name any variables as bool, true or
false. These words are far too often keywords in most programming
langauges.

My problem with VLAs
is that they let you allocate an arbitrary amount of memory during
execution with no mechanism for detecting or handling an allocation
error.

The language (with the revised standard) manages it and guarantees the
memory allocation for VLAs, normal arrays, ints and doubles. It is
promising it, right?

Do you worry if this fails: Char arr[999999];

Memory allocation and what to do with failures of the same are more
pertinent to the operating system and the programmer. The language
really has no control over these issues. It provides a mechanism to do
the task. The policy decisions should be taken by the programmer or the
operating system.

 

[Suman]

typedef int32 bool_t;
#define true 1
#define false 0

This works fine, why bother to add three keywords and modify the
language.

Then you haven't run into issues when someone flips the true/false
values and you land in utter confusion. Bad programming can never
be cured; but standardization is a prevention.

The language (with the revised standard) manages it

Manages? The Language? I'd be surprised. I believe its up to the
compiler.

and guarantees the
memory allocation for VLAs, normal arrays, ints and doubles. It is
promising it, right?

C&V, please.

Do you worry if this fails: Char arr[999999];

No. Because there is no `Char' type.

 

[Richard Heathfield]

Frederick Gotham said:

Keith Thompson posted:




Do you think the C99 Standard will ever replace the C90 Standard, or do
you think the C community is content with C90 and does not want to change
anything?

I think the part of the C community that cares about portability wants a
widely-implemented standard, which it already has. Until C99 becomes as
widespread as C90, why would anyone use it if they need portability?

And the part of the C community that couldn't give two hoots about
portability aren't interested in the Standard anyway - they just want
something that works on /their/ compiler, and many such people think the
Standard (if they've even heard of it) takes second place to their compiler
documentation.

Is there anything particularly unpleasant about C99?

The presumption that people are using it, which is a far from accurate
presumption. I am not using C99, and as far as my compiler is concerned the
// comment is a syntax error, and I wish people wouldn't use it in clc
because it means an extra step for me before I can compile the code.

When I first started
to realise that everyone was using C90, my first presumption about the
situation was that there was some horrible feature about C99 which nobody
liked (VLA's maybe?)?

Non-portability is a ghastly feature.

Are there ever times when you're programming in C that you would like to
use a C99 feature that isn't present in C90?

No, but there are certainly times when I wish other people wouldn't use a
C99 feature that isn't present in C90.

 

[Richard Heathfield]

lovecreatesbeauty said:

typedef int32 bool_t;
#define true 1
#define false 0

This works fine,

It doesn't even compile, here.

why bother to add three keywords and modify the language.

Four.

Removing 32 from your code allows it to compile, but it still violates a
POSIX convention.

Why not just assume that 0 is false and non-zero is true?

The language (with the revised standard) manages it and guarantees the
memory allocation for VLAs, normal arrays, ints and doubles.

Up to a point.

It is promising it, right?

No, it promises you can definitely have /one/ object 65535 bytes in size.

Do you worry if this fails: Char arr[999999];

It doesn't even compile. And if it did, it isn't guaranteed to succeed. No,
I don't worry if it fails because I Am Not Stupid Enough To Do It Like That
In The First Place.