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?

--

Frederick Gotham

[Sjouke Burry]

Frederick Gotham wrote:

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]

Frederick Gotham wrote:

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]

Frederick Gotham <fg*******@SPAM.com> writes:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Frederick Gotham wrote:

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.

--
pete

[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

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

Frederick Gotham

[Ben Pfaff]

pete <pf*****@mindspring.com> writes:

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

That's partly because the font size was increased.
--
"Give me a couple of years and a large research grant,
and I'll give you a receipt." --Richard Heathfield

[pete]

Frederick Gotham wrote:

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?

<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

[pete]

Ben Pfaff wrote:

pete <pf*****@mindspring.com> writes:

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

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.

--
pete

[Keith Thompson]

pete <pf*****@mindspring.com> writes:

Frederick Gotham wrote:

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?

<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.

[...]

I myself am not crazy about VLA's.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Peter Nilsson]

Frederick Gotham wrote:

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,

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.

--
Peter

[Rouben Rostamian]

In article <LR*******************@news.indigo.ie>,
Frederick Gotham <fg*******@SPAM.com> wrote:

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
--
Rouben Rostamian

[Ben Pfaff]

"Peter Nilsson" <ai***@acay.com.au> writes:

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.
--
"I'm not here to convince idiots not to be stupid.
They won't listen anyway."
--Dann Corbit

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.edu> writes:

"Peter Nilsson" <ai***@acay.com.au> writes:

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.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[lovecreatesbeauty]

Keith Thompson wrote:

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]

lovecreatesbeauty wrote:

Keith Thompson wrote:

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.

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]

lovecreatesbeauty wrote:

Keith Thompson wrote:

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.

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.

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

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. lovecreatesbeauty

[Richard Heathfield]

Frederick Gotham said:

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?

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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

lovecreatesbeauty said:

Keith Thompson wrote:

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,

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?

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.

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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[santosh]

Richard Heathfield wrote:

lovecreatesbeauty said: .... snip ...
Why not just assume that 0 is false and non-zero is true?

As an aside, is there an explanation why certain function in the
standard library return 0 to indicate success while certain others
return 1 for the same? Is it a historical/legacy issue or is there a
method behind the apparent inconsistency?

I use 1 to indicate success and 0 for failure in all my private
functions, since that's the convention adopted in electronics.

[Mark F. Haigh]

Richard Heathfield wrote:

Frederick Gotham said:

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?

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?

Come on, quit being so negative. Having everybody agree on "restrict"
now, for example, is better than a bunch of subtly incompatible type
aliasing optimization extensions later.
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.
C99-isms are creeping in, slowly. "restrict" works on Intel C, GCC,
the Sun C, and the HPUX C, and IBM VisualAge for AIX. The stdint.h
typedefs are working their way into just about everywhere. No need for
despair.

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.

<snip>

I use C99 features where I can. Most have hackish or platform-specific
fallbacks that work well enough. As an example, it's nice to use the
struct hack as a fallback-only thing.

Mark F. Haigh
mf*****@sbcglobal.net

[Richard Bos]

"santosh" <sa*********@gmail.com> wrote:

Richard Heathfield wrote:

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

As an aside, is there an explanation why certain function in the
standard library return 0 to indicate success while certain others
return 1 for the same? Is it a historical/legacy issue or is there a
method behind the apparent inconsistency?

Most of it is on the one hand a varying value (say, a character count)
for success, 0 for failure; and on the other hand a boolean 0 for found
no exception, 1 for found an exception. I haven't checked all of the
library to see whether this is kept to consistently, but it does cover
the majority, I think.

Richard

[Keith Thompson]

"lovecreatesbeauty" <lo***************@gmail.com> writes:

Keith Thompson wrote:

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.

Because <EXAGGERATE>everybody</EXAGGERATE> does the same thing, but
slightly differently. With a consistent set of declarations in the
standard, we can avoid inconsistencies and conflicts.

Try compiling a program that uses two libraries, both of which define
"true", "false", and "bool", but with incompatible definitions of
"bool".

(BTW, why int32 rather than int?)

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?

What promise are you talking about?
Do you worry if this fails: Char arr[999999];

I wouldn't put a declaration like that inside a function. But this:

char arr[n];

can work just fine until somebody calls the function with n = 999999.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

santosh said:

Richard Heathfield wrote:

lovecreatesbeauty said: ... snip ...

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

As an aside, is there an explanation why certain function in the
standard library return 0 to indicate success while certain others
return 1 for the same?

Off-hand, I can't think of any C standard library functions that return 0 to
mean "success", but no doubt you have an example in mind. Having said that,
I generally use 0 for that purpose, which leaves all the other possible int
values for documenting the exact error that occurred. When I make an
exception, it is for pointer-returning functions, where clearly NULL is the
only value I can reasonably choose to mean "oopsie" (e.g. "couldn't
allocate this resource").

Is it a historical/legacy issue or is there a
method behind the apparent inconsistency?

Actually, the consistency is pretty good! But different kinds of function
have different purposes, so the consistency is within function groups,
rather than across the board. This is not unreasonable.

Functions that determine a truth/falsehood - is* - return 0 for false and
non-zero for true.

Functions that determine a relationship - *cmp, and our own int(*)(const
void *, const void *) - return < 0 for less, 0 for equal, and > 0 for
greater.

Functions that yield a count - fread, fwrite, strlen, strspn, strcspn -
return 0 for a 0 count, > 0 for a non-zero count.

Functions that yield a pointer - fgets, malloc, strstr, strtok - return a
valid pointer if they can, or NULL if they can't.

Functions that yield the result of a calculation - sin, cos, tan, strtol,
strtod - tend to report errors via some other mechanism than their return
value (e.g. domain errors, endptr, whatever).

Functions that retrieve or process a single character - getc, fgetc,
getchar, to* - yield EOF on error.

I do not claim that the consistency within groups is 100%, but off the top
of my head I can't think of any counter-examples within the categories I've
listed.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Mark F. Haigh said:

Richard Heathfield wrote:

<snip>

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?

Come on, quit being so negative. Having everybody agree on "restrict"
now, for example, is better than a bunch of subtly incompatible type
aliasing optimization extensions later.

Not if it stops my program from compiling.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[pete]

santosh wrote:

Richard Heathfield wrote:

lovecreatesbeauty said: ... snip ...

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

Nothing could be simpler!
As an aside, is there an explanation why certain function in the
standard library return 0 to indicate success while certain others
return 1 for the same? Is it a historical/legacy issue or is there a
method behind the apparent inconsistency?

I use 1 to indicate success and 0 for failure in all my private
functions, since that's the convention adopted in electronics.

I think main is the only function in the standard,
(not to be confused with the standard library)
that returns 0 for success.
Returning 0 for success enables various modes of failure
to be indicated by various non zero return values,
none of which are mentioned in the standard,
but which would have to be implementation defined.

--
pete

[Harald van Dijk]

Richard Heathfield wrote:

Mark F. Haigh said:

Richard Heathfield wrote:

<snip>

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?

Come on, quit being so negative. Having everybody agree on "restrict"
now, for example, is better than a bunch of subtly incompatible type
aliasing optimization extensions later.

Not if it stops my program from compiling.

It shouldn't if you define restrict as an empty macro in C90 mode, or
otherwise hide it.

[Richard Heathfield]

Harald van D?k said:

Richard Heathfield wrote:

Mark F. Haigh said:

> Richard Heathfield wrote:

<snip>

>> 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?
>
> Come on, quit being so negative. Having everybody agree on "restrict"
> now, for example, is better than a bunch of subtly incompatible type
> aliasing optimization extensions later.

Not if it stops my program from compiling.

It shouldn't if you define restrict as an empty macro in C90 mode, or
otherwise hide it.

I have found that the best way to hide restrict is not to define it at all,
not to use it, not to even think about using it, except of course as a
perfectly normal identifier. As far as I'm concerned, it's in user
namespace, and the C standardeers have no business polluting that space.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Harald van Dijk]

Richard Heathfield wrote:

Harald van D?k said:

Richard Heathfield wrote:

Mark F. Haigh said:

> Richard Heathfield wrote:

<snip>

>> 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?
>
> Come on, quit being so negative. Having everybody agree on "restrict"
> now, for example, is better than a bunch of subtly incompatible type
> aliasing optimization extensions later.

Not if it stops my program from compiling.

It shouldn't if you define restrict as an empty macro in C90 mode, or
otherwise hide it.

I have found that the best way to hide restrict is not to define it at all,
not to use it, not to even think about using it, except of course as a
perfectly normal identifier. As far as I'm concerned, it's in user
namespace, and the C standardeers have no business polluting that space.

Sorry, I think I misunderstood your previous message. I thought you
meant a C99 program using "restrict" would not compile with a C90
compiler, but you probably meant a C90 program using an identifier
"restrict" would not compile with a C99 compiler, right? If so, I think
it's annoying if you actually have such code, but pretty much
unavoidable unless you want to use something like __restrict instead. I
haven't seen restrict myself as an identifier, but I have seen inline()
functions which cause the same problems.

[Roberto Waltman]

"lovecreatesbeauty" wrote:

Keith Thompson wrote:

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

Mine also.
typedef int32 bool_t;
#define true 1
#define false 0

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

Because not everybody will do exactly that. I have seen all of the
following:

typedef <some_int_type> bool;
typedef <some_int_type> bool_t;
typedef <some_int_type> Bool;
typedef <some_int_type> Bool_t;
typedef <some_int_type> BOOL;
typedef <some_int_type> boolean;
/* for Fortranistas: */
typedef <some_int_type> logical;
/* and Logical, and LOGICAL ... */

And so on. Use any possible variation of <some_int_type>, and then
duplicate the list using #define instead of typedef.
Then continue with:

#define true 1
#define true (~false)
#define True 1
#define TRUE 1
#define T 1
#define true (-1)
#define True (-1)
#define TRUE (-1)
#define T (-1)

enum { TRUE = ... }

Tautology of the day: If it is not standardized unless it is in the
standard.

[Frederick Gotham]

lovecreatesbeauty posted:

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

That's flawed, and I'll show you why:

int Func1() { return 5; }

int Func2() { return 1; }

int main(void)
{
bool_t result1 = Func1();

bool_t result2 = Func2();

if ( result1 == result2 ) DoSomething();
}
(The preceeding snippet would work as expected in C++ with the built-in
"bool" type.)

--

Frederick Gotham

[Tom St Denis]

Frederick Gotham wrote:

int main(void)
{
bool_t result1 = Func1();

bool_t result2 = Func2();

if ( result1 == result2 ) DoSomething();
}

(The preceeding snippet would work as expected in C++ with the built-in
"bool" type.)

You shouldn't use == for bool types though. It's a logical type not
arithmetic type [a distinction solely made in the intent of the program
and not the C language].

if (result1 && result2) DoSomething();

Would work fine in C too.

Tom

[Roberto Waltman]

Roberto Waltman <us****@rwaltman.net> wrote:

...
Tautology of the day: If it is not standardized unless it is in the
standard.

Argh! Not enough coffee. Tautology of the day: It is not standardized
unless it is in the standard.

[lovecreatesbeauty]

Richard Heathfield wrote:

lovecreatesbeauty said:

Keith Thompson wrote: <snip>

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.

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.

A whole C source file in a well format and without typo can't
certainly be supposed as quality code. Do you agree?

What I meant was even a single int i; or int arr[1] like those in the
following small snippet has a chance to fail. (Perhaps this example can
not demonstrate the dangerous. People with wisdom like you, Mr.
Heathfield may do it, don't you?). You pay attention to VLA, you also
pay attention to int i, it's great.

int main(void)
{
for (;;)
{
int i;
int arr[1];
/*do calculations on the above objects*/
}
}
No,
I don't worry if it fails because I Am Not Stupid Enough To Do It Like That
In The First Place.

People never declare themselves as smart ("Not Stupid") have
written Linux, GCC, etc.. I'm using both Linux and GCC, perhaps
you're using both also, or you're using the substitutes of
yourself. Can you show us some of you smart softwares? Have you got
users for them in c.l.c?

Do you think people in C standard committee all are more stupid than
you and provide you such a stupid broken feature?

lovecreatesbeauty

[Frederick Gotham]

Tom St Denis posted:

if (result1 && result2) DoSomething();

My intention was not to execute "DoSomething" if both were true, but rather
if both were the same. Thus in C++, we have:
if ( result1 == result2 ) DoSomething();
But to make this work in C, you'd need:
if( result1 && result2 || !(result1 || result2) ) DoSomething();

--

Frederick Gotham

[lovecreatesbeauty]

Keith Thompson wrote:

Try compiling a program that uses two libraries, both of which define
"true", "false", and "bool", but with incompatible definitions of
"bool".

Most of things in C (library) fail if this happens.

[Richard Heathfield]

lovecreatesbeauty said:

<snip>

A whole C source file in a well format and without typo can't
certainly be supposed as quality code. Do you agree?
I don't know, since I don't know what you're talking about.
What I meant was even a single int i; or int arr[1] like those in the
following small snippet has a chance to fail.
The C Standard guarantees that you can have at least one object at least
32767 (in C90) or 65535 (in C99) bytes in size.

<snip>
Do you think people in C standard committee all are more stupid than
you and provide you such a stupid broken feature?

I don't think the ISO C committee members are stupid, but I do think they're
human, and they are certainly capable of making mistakes - as C99 shows
very clearly.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Frederick Gotham said:

Tom St Denis posted:

if (result1 && result2) DoSomething();

My intention was not to execute "DoSomething" if both were true, but
rather if both were the same. Thus in C++, we have:
if ( result1 == result2 ) DoSomething();
But to make this work in C, you'd need:
if( result1 && result2 || !(result1 || result2) ) DoSomething();

No, you can do:

if(!!result1 == !!result2) DoSomething();

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[santosh]

lovecreatesbeauty wrote:

Richard Heathfield wrote:

lovecreatesbeauty said:

Keith Thompson wrote: <snip>> 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.
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.

A whole C source file in a well format and without typo can't
certainly be supposed as quality code. Do you agree?

Indeed, just as stringing words together can be considered as proper
English.
You might try being less philosophical and more lucid.
What I meant was even a single int i; or int arr[1] like those in the
following small snippet has a chance to fail.
No. Static allocation cannot fail. If it fails, the system would not
even load your executable and you'd probably be in serious trouble.
That happens only when you're out memory. This has nothing to do with
the C program or the compiler but rather the runtime condition of the
target system.
(Perhaps this example can
not demonstrate the dangerous. People with wisdom like you, Mr.
Heathfield may do it, don't you?). You pay attention to VLA, you also
pay attention to int i, it's great.
You should *really* try to be more lucid.

No,
I don't worry if it fails because I Am Not Stupid Enough To Do It Like That
In The First Place.

People never declare themselves as smart ("Not Stupid") have
written Linux, GCC, etc.. I'm using both Linux and GCC, perhaps
you're using both also, or you're using the substitutes of
yourself. Can you show us some of you smart softwares? Have you got
users for them in c.l.c?

You've completely missed the point that Richard was making. He said
that he won't use constructs which are likely to fail. This has nothing
to do with Richard's smartness, but rather, is a trait of any good
programmer.

BTW, Richard has coauthored a well respected book on C. It called 'C
Unleashed'. Maybe you should look over it sometime before casting
aspersions on his intelligence.
Do you think people in C standard committee all are more stupid than
you and provide you such a stupid broken feature?

I understand that you're not a native English speaker, but you've
*completely* misunderstood the meaning of Richard's post. Try to first
improve you English comprehension and writing skills before posting too
many more posts.

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalid> writes:
[...]

I have found that the best way to hide restrict is not to define it at all,
not to use it, not to even think about using it, except of course as a
perfectly normal identifier. As far as I'm concerned, it's in user
namespace, and the C standardeers have no business polluting that space.

If you mean they *had* no business polluting the user namespace, I can
see your point, but the fact is they've already done so, and that bell
can't be unrung. Realistically, it's best to avoid using "restrict"
as an identifier; there's always the possibility that, some day in the
distant future, someone will want to compile your code with a compiler
that doesn't have a C90 mode.

I wouldn't avoid "new" and "class" in C code; C++ is a different
language. But C99 is a new version of the same language, and it just
might catch on.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.com> writes:

lovecreatesbeauty posted:

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

That's flawed, and I'll show you why:

int Func1() { return 5; }

int Func2() { return 1; }

int main(void)
{
bool_t result1 = Func1();

bool_t result2 = Func2();

if ( result1 == result2 ) DoSomething();
}

The flaw is in the misuse of the bool (or bool_t) type, not in its
definition. A logically true value in C is non-zero, not necessarily 1;
C99's _Bool and <bool.h> doesn't change that.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

<snip>

I wouldn't avoid "new" and "class" in C code; C++ is a different
language. But C99 is a new version of the same language, and it just
might catch on.

Yes, it might, and so of course I /do/ avoid clashes in C90 code. I might
/think/ about using restrict as an identifier, but I don't actually do it.

(In fact, a few years ago I discovered that I had done precisely that, in a
program written before I'd ever heard of C99. Although that program has
never encountered a C99 compiler, I changed the code anyway. ISTR that I
used "constrain" instead.

But C0X people should bear in mind that our namespace is already crowded
enough, and should invade it no more.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Al Balmer]

On Fri, 30 Jun 2006 01:12:13 GMT, Frederick Gotham
<fg*******@SPAM.com> wrote:

If we look at a programming language such as C++: When an updated Standard
comes out, everyone adopts it and abandons the previous one.
No they don't, not even in C++. The best that many vendors claim even
now is "substantially compliant."
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?

For the same reasons that conformance to the C++ standard is not
immediate and universal. Take a minute and actually think about the
process.

Most compilers are getting up to the new standard gradually. Some
advertise it, and some don't, but every one of the several compilers I
work with has implemented sizable chunks of the C99 standard.

--
Al Balmer
Sun City, AZ

[Al Balmer]

On 30 Jun 2006 07:28:33 -0700, "lovecreatesbeauty"
<lo***************@gmail.com> wrote:

Richard Heathfield wrote: <snip>

No,
I don't worry if it fails because I Am Not Stupid Enough To Do It Like That
In The First Place.
People never declare themselves as smart ("Not Stupid") have
written Linux, GCC, etc.. I'm using both Linux and GCC, perhaps
you're using both also, or you're using the substitutes of
yourself. Can you show us some of you smart softwares? Have you got
users for them in c.l.c?

Heh. Google "Richard Heathfield" (with the quotes.) You might find
some enlightenment on that subject.
Do you think people in C standard committee all are more stupid than
you and provide you such a stupid broken feature?

lovecreatesbeauty

--
Al Balmer
Sun City, AZ

[Frederick Gotham]

Richard Heathfield posted:

But to make this work in C, you'd need:
if( result1 && result2 || !(result1 || result2) ) DoSomething();

No, you can do:

if(!!result1 == !!result2) DoSomething();

Touché!

--

Frederick Gotham

[Keith Thompson]

"lovecreatesbeauty" <lo***************@gmail.com> writes:

Richard Heathfield wrote:

lovecreatesbeauty said:

> Keith Thompson wrote: <snip> >> 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.

[snip] People never declare themselves as smart ("Not Stupid") have
written Linux, GCC, etc.. I'm using both Linux and GCC, perhaps
you're using both also, or you're using the substitutes of
yourself. Can you show us some of you smart softwares? Have you got
users for them in c.l.c?

Do you think people in C standard committee all are more stupid than
you and provide you such a stupid broken feature?

(This was a response to something Richard wrote; see upthread for
context.)

I never said that anything or anyone was "stupid".

If you view VLAs as an alternative to malloc() (the only portable way
in C90 to do the equivalent kind of allocation), VLAs have the
disadvantage that there's no way to detect or handle an allocation
failure. If the system can't allocate enough memory, the behavior is
undefined. malloc() by contrast, safely returns a null pointer on
failure.

Yes, it's true that VLAs are just like ordinary objects in this sense;
there's not much difference between this:
int arr[1000000];
and this:
int len = 1000000;
int vla[len];
(apart from the latter being illegal in C90). The difference is that
a VLA can cause an allocation failure that depends on the value of a
variable at run time, perhaps on user input.

I'm not sure there's any good way to design VLAs that would eliminate
this problem. I suppose an allocation failure could cause &vla to be
NULL, but that's ugly. A generalized exception mechanism in which any
allocation failure of an automatic variable raises an exception that
can be handled by the function's caller would do the trick, but that
would be a major change to the language.

I'm not saying that VLAs shouldn't have been added to the language,
just that you have to be careful using them -- and sometimes being
careful isn't enough.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ben Pfaff]

Al Balmer <al******@att.net> writes:

On 30 Jun 2006 07:28:33 -0700, "lovecreatesbeauty"
<lo***************@gmail.com> wrote:

People never declare themselves as smart ("Not Stupid") have
written Linux, GCC, etc.. I'm using both Linux and GCC, perhaps
you're using both also, or you're using the substitutes of
yourself. Can you show us some of you smart softwares? Have you got
users for them in c.l.c?

Heh. Google "Richard Heathfield" (with the quotes.) You might find
some enlightenment on that subject.

Richard wrote (much of) a book on C. Does that make him an
expert?
--
A competent C programmer knows how to write C programs correctly,
a C expert knows enough to argue with Dan Pop, and a C expert
expert knows not to bother.

[Default User]

Frederick Gotham wrote:

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

This is a rather bogus description. C++ had its first standard approved
in 1998. Some years later, a technical corrigendum that mostly cleaned
up some stuff was approved, around 2003. This made no substantive
change to the language. The 1998 standard was in no way "abandoned" by
anyone. There is another in work now that will add some new library
features.

The 1999 C standard was a substantial revision over the 1990 one. The
situations are not comparable.


Brian

[Richard Heathfield]

Ben Pfaff said:

<snip>

Richard wrote (much of) a book on C. Does that make him an
expert?

Obviously not. After all, so did Herbert Schildt.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)