C 99 compiler access

[E. Robert Tisdale]

I have access to a wide variety of different platforms here at JPL
and they all have pretty good C 99 compilers.

Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?

[Richard Tobin]

In article <cg**********@nntp1.jpl.nasa.gov>,
E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

I have access to a wide variety of different platforms here at JPL
and they all have pretty good C 99 compilers.

If JPL pays me to write some C code for them, I'll bear it in mind.

-- Richard

[Eric Sosman]

E. Robert Tisdale wrote:

I have access to a wide variety of different platforms here at JPL
and they all have pretty good C 99 compilers.

Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?

Yes; see Section 1.42.8 paragraph 9. It is permitted
to back-slide to any valid array element or to one element
before the start of the array, provided the element is not
actually referenced. Back-sliding by an amount greater than
the number of padding bits is undefined; "lame" refers to the
condition of the user after blistering his gluteal muscles
by back-sliding with insufficient padding.

However, "excuse" is used only as a synonym for "rationale,"
and as we all know the Rationale is non-normative.

--
Er*********@sun.com

[Mac]

On Fri, 27 Aug 2004 14:39:40 -0700, E. Robert Tisdale wrote:

I have access to a wide variety of different platforms here at JPL
and they all have pretty good C 99 compilers.

Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?

As I understand it, the argument against moving to C99 rests on the
premise that there is a lack of conforming implementations.

It sounds like you are claiming that there are actually a wide variety
of conforming implementations at your disposal. If this is the case,
then maybe your point is a good one. And it would seem that there is
nothing holding you back from using C99 features in your code.

But just to confirm, do the authors or vendors of the compilers and
libraries you are referring to actually claim C99 conformance for them?
And are they widely available to other people on other platforms?

--Mac

[E. Robert Tisdale]

Mac wrote:

E. Robert Tisdale wrote:

I have access to a wide variety of different platforms here at JPL
and they all have pretty good C 99 compilers.

Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?

As I understand it,
the argument against moving to C99 rests on the premise that
there is a lack of conforming implementations.

It sounds like you are claiming that there are actually a wide variety
of conforming implementations at your disposal. If this is the case,
then maybe your point is a good one. And it would seem that there is
nothing holding you back from using C99 features in your code.

But just to confirm, do the authors or vendors of the compilers and
libraries you are referring to actually claim C99 conformance for them?
And are they widely available to other people on other platforms?

I don't even know of *any* implementation
that actually claims C 89/90 compliance (conformance)
let alone C 99 compliance.
That doesn't prevent people from writing C 89/90 code.

So far, the closest to compliance are the Comeau compilers:

http://www.comeaucomputing.com/

I have GNU, MIPSPro and Intel C compilers
that support all of the C99 features that I have found useful so far.

[CBFalconer]

Richard Tobin wrote:

E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

I have access to a wide variety of different platforms here at
JPL and they all have pretty good C 99 compilers.

If JPL pays me to write some C code for them, I'll bear it in
mind.

Considering the normal accuracy of his comments, I have grave
doubts. You will note he fails to specify the compilers involved,
which makes this just another Trollsdale troll.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Mike Wahler]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cg**********@nntp1.jpl.nasa.gov...

I have access to a wide variety of different platforms here at JPL
and they all have pretty good C 99 compilers.

Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?

Why do you believe JPL's 'wide variety' of platforms contains
all those used by everyone else?
-Mike

[E. Robert Tisdale]

Mike Wahler wrote:

E. Robert Tisdale wrote:

I have access to a wide variety of different platforms here at JPL
and they all have pretty good C 99 compilers.

Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?

Why do you believe JPL's 'wide variety' of platforms
contains all those used by everyone else?

I didn't say that it does.
We might have one of every platform here at JPL
but I'm not sure that we do.
But I'm pretty sure that we have most viable platforms
and I've used C 99 compilers on most of them.

[Mike Wahler]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cg*********@nntp1.jpl.nasa.gov...

Mike Wahler wrote:

E. Robert Tisdale wrote:

I have access to a wide variety of different platforms here at JPL
and they all have pretty good C 99 compilers.

Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?
Why do you believe JPL's 'wide variety' of platforms
contains all those used by everyone else?

I didn't say that it does.
We might have one of every platform here at JPL
but I'm not sure that we do.
But I'm pretty sure

Why are you pretty sure?
that we have most viable platforms
'Viable'? That's subject to context.
and I've used C 99 compilers on most of them.

So, what's your point? From your original post:

"Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?"
Who cares if or why someone does or does not use new C99
features? And for some platforms, yes, lack of an implementation
(or at least one of 'acceptable' quality) is indeed a legitimate
reason. But that needn't be the *only* reason. Perhaps
a developer's target platform does have a good C99 implementation
available. Why would someone switch when c90 is still sufficient?

You're implying that not using the 'latest and greatest'
tools, simply because they exist, is somehow 'backsliding'.
That's utter nonsense.

-Mike

[Malcolm]

"Mike Wahler" <mk******@mkwahler.net> wrote

You're implying that not using the 'latest and greatest'
tools, simply because they exist, is somehow 'backsliding'.
That's utter nonsense.

The difference is that C99 was designed by a standards body. There is no
point in having a "standard" that is not widely implemented. So the present
situation is very undesireable, but it is largely ANSI's fault, because the
extensions were neither so minimal that they could be trivially implemented
(a #define for bool, a vnsprintf() function, etc) nor were like the C++
extensions, very far reaching and offering greatly enhanced functionality.
Instead we had a lot of feature of dubious use which require rewrites of the
compiler. For instance variables can now be declared anywhere, which seems
to be just a way of making code less organised and harder to read, and
variable arrays are allowed. Since a variable length array cannot fail, and
the programmer won't know the array length at run time, this is asking for a
security exploit.

[E. Robert Tisdale]

Malcolm wrote:

Mike Wahler wrote:

You're implying that not using the 'latest and greatest'
tools, simply because they exist, is somehow 'backsliding'.
That's utter nonsense.
The difference is that C99 was designed by a standards body.
There is no point in having a "standard" that is not widely implemented.

Which begs the question,
"Is the ANSI/ISO C 99 standard 'widely implemented'?"
It appears to me to be widely implemented now.
So the present situation is very undesireable but it is largely ANSI's fault
because the extensions were neither so minimal that they could be trivially implemented
(a #define for bool, a vnsprintf() function, etc.) nor were like the C++ extensions,
very far reaching and offering greatly enhanced functionality. Instead,
we had a lot of feature of dubious use which require rewrites of the compiler.
For instance, variables can now be declared anywhere,
which seems to be just a way of making code less organised
and harder to read, and variable arrays are allowed.
Since a variable length array cannot fail,
and the programmer won't know the array length at run time,
this is asking for a security exploit.

I suppose you would describe yourself as a backslider. :-)

[Malcolm]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote

I suppose you would describe yourself as a backslider. :-)

I wasn't on the C99 committee, nor did I make any suggestions to it. So I am
under no obligation to defend its actions nor to see that its decisions are
implemented.
The situation is that very few C99 compilers are in existence, five years
after the standard was proposed. I am not going to use what influence I have
to encourage vendors to ship C99-compliant compilers, but on the other hand
if the standard did take off and customers started asking for C99-conforming
code, then I would oblige.

[E. Robert Tisdale]

Malcolm wrote:

I wasn't on the C99 committee, nor did I make any suggestions to it.
So I am under no obligation to defend its actions
nor to see that its decisions are implemented.
The situation is that very few C99 compilers are in existence
five years after the standard was proposed.
What do you mean by "very few".
There aren't many C compilers that comply with C 89
fifteen years after the standard was proposed.
I am not going to use what influence I have
to encourage vendors to ship C99-compliant compilers
but, on the other hand, if the standard did take off
and customers started asking for C99-conforming code,
then I would oblige.

I think that the C 99 standard is
"backward compatible" with the C 89 standard
so C 89 code is. by definition, "C99-conforming code".

How will you know when the [C 99] standard does "take off"?
What evidence are you looking for?
Maybe it has already "taken off" and you just didn't notice.

[Jens.Toerring]

E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

Malcolm wrote:

I wasn't on the C99 committee, nor did I make any suggestions to it.
So I am under no obligation to defend its actions
nor to see that its decisions are implemented.
The situation is that very few C99 compilers are in existence
five years after the standard was proposed.

What do you mean by "very few".
There aren't many C compilers that comply with C 89
fifteen years after the standard was proposed.

Can you name just a few commonly used ones that don't?
My impression is that basically all are C89 compliant.

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[E. Robert Tisdale]

Je***********@physik.fu-berlin.de wrote:

E. Robert Tisdale wrote:

What do you mean by "very few".
There aren't many C compilers that comply with C 89
fifteen years after the standard was proposed.

Can you name just a few commonly used ones that don't?
My impression is that basically all are C89 compliant.

To my knowledge,

there are no C compilers that claim to be fully compliant
with the ANSI/ISO C 89/90 language standard.

The only C compiler that comes close is the Comeau compiler:

http://www.comeaucomputing.com/

All C compilers come with a disclaimer
something like the one that came with my GNU C compiler:

GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.

Do you know of any C compiler that *does* claim to comply
with the ANSI/ISO C 89/90 standard?

[Robert Wessel]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cg**********@nntp1.jpl.nasa.gov>...

I don't even know of *any* implementation
that actually claims C 89/90 compliance (conformance)
let alone C 99 compliance.

OK, from page xii of the "C Language Reference" from the MS VC7.0
(circa 1991) package (it was handy):

"ANSI Conformance: Microsoft C version 7.0 conforms to the standard
for the C language as set forth in the American National Standard
(hereinafter referred to as the ANSI C standard). Microsoft
extensions to the ANSI C standard are noted in the text and syntax of
this manual as well as in the online references. Because the
extensions are not a part of the ANSI C standard, their use may
restrict portability of programs between systems. By default the
Microsoft extensions are enabled. To disable the extensions, specify
/Za on the command line. With /Za, all non-ANSI code generates errors
or warnings." (Retyped from the original hardcopy by RW, apologies in
advance for any transcription errors).

Essentially the identical paragraph is included in the online doc of
several of the newer versions of the compiler.

While one might quibble about the degree to which the MS compilers
actual meet that claim, the claim of C89/90 compliance is clearly
made.

[Robert Gamble]

On Fri, 27 Aug 2004 16:03:40 -0700, E. Robert Tisdale wrote:

Mac wrote:

E. Robert Tisdale wrote:

I have access to a wide variety of different platforms here at JPL
and they all have pretty good C 99 compilers.

Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?

As I understand it,
the argument against moving to C99 rests on the premise that
there is a lack of conforming implementations.

It sounds like you are claiming that there are actually a wide variety
of conforming implementations at your disposal. If this is the case,
then maybe your point is a good one. And it would seem that there is
nothing holding you back from using C99 features in your code.

But just to confirm, do the authors or vendors of the compilers and
libraries you are referring to actually claim C99 conformance for them?
And are they widely available to other people on other platforms?

I don't even know of *any* implementation
that actually claims C 89/90 compliance (conformance)
let alone C 99 compliance.
That doesn't prevent people from writing C 89/90 code.

So far, the closest to compliance are the Comeau compilers:

http://www.comeaucomputing.com/

I have GNU, MIPSPro and Intel C compilers
that support all of the C99 features that I have found useful so far.

Can you point out where gcc does not support full c90 compliance? The
documentation implies full conformance to c90:

"GCC supports three versions of the C standard, although support for the
most recent version is not yet complete."

Where the 3 versions are c89/c90, c94/c95, and c99 respectively.

Rob Gamble

[Mike Wahler]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cg**********@nntp1.jpl.nasa.gov...

I think that the C 99 standard is
"backward compatible" with the C 89 standard
Nope.
so C 89 code is. by definition, "C99-conforming code".

The following conforms to C89 but not C99:

main()
{
return 0;
}

-Mike

[E. Robert Tisdale]

Robert Gamble wrote:

"GCC supports three versions of the C standard,
although support for the most recent version is not yet complete."

Can you give us a pointer (URL) for this quote?

[Keith Thompson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Robert Gamble wrote:

"GCC supports three versions of the C standard, although support
for the most recent version is not yet complete."

Can you give us a pointer (URL) for this quote?

It's in the documentation provided along with gcc; "info gcc"
and search ('s') for "gcc supports".

See also <http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/Standards.html>.

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

[Flash Gordon]

On Sun, 29 Aug 2004 00:47:59 -0700
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Robert Gamble wrote:

"GCC supports three versions of the C standard,
although support for the most recent version is not yet complete."

Can you give us a pointer (URL) for this quote?

http://gcc.gnu.org/onlinedocs/gcc-3....html#Standards

Also
http://gcc.gnu.org/onlinedocs/gcc-3....Implementation
for required documentation on implementation defined behaviour.

For information about the library read
http://gcc.gnu.org/onlinedocs/gcc-3....rd%20Libraries

Taking these three things together you have a claim for C89 compliance
on Linux and C95 compliance on Linux.

From the man page of the compiler that is part of the development system
for SCO (spit) Openserver 5.0.7 we have "For example, to request the
complete and strict ANSI C environment, you can use the option
combination -Xc -a ansi". I can't be bothered to track down the full
documentation.

The C compiler by Texas Instruments I used a few years ago for the
TMS320C25 also claimed C89 conformance, obviously as a freestanding
implementation. It mentions ANSI compliance for the latest tools in
http://focus.ti.com/lit/ug/spru376a/spru376a.pdf I don't have the full
documentation as I no longer do embedded development.

I could probably go on finding C compilers claiming ANSI/ISO compliance
either from memory or hunting the web, but I've made the point.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Richard Tobin]

In article <cg**********@nntp1.jpl.nasa.gov>,
E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

There aren't many C compilers that comply with C 89
fifteen years after the standard was proposed.

Can you name just a few commonly used ones that don't?

To my knowledge,

there are no C compilers that claim to be fully compliant
with the ANSI/ISO C 89/90 language standard.

The question was about whether they comply, not whether they claim to
comply.

-- Richard

[Rouben Rostamian]

In article <cg**********@newsg3.svr.pol.co.uk>,
Malcolm <ma*****@55bank.freeserve.co.uk> wrote:
[about features introduced in C99]

Instead we had a lot of feature of dubious use which require rewrites
of the compiler. For instance variables can now be declared anywhere,
which seems to be just a way of making code less organised and harder
to read,

I agree with your statement in general -- declaration of variables
in the middle of a function block can make the code less organized
and harder to follow.

There is one exception, however. The new feature that allows local
declaration of loop indices, as in:

for (int i=0; i<n; i++)

is a positive change. It makes the code easier to read and reduces
name pollution within the body of a function.

--
rr

[Ben Pfaff]

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

Instead we had a lot of feature of dubious use which require rewrites of the
compiler. For instance variables can now be declared anywhere, which seems
to be just a way of making code less organised and harder to read, [...]

I disagree. Declaring a variable in mid-block is a valuable way
to reduce the scope of that variable, giving the programmer less
time to screw it up. Furthermore, a variable declared in
mid-block can usually be initialized in the declaration, which
means there's a bigger chance it can be marked `const', which in
turn gives the programmer less to screw up.

--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Malcolm]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote

To my knowledge,

there are no C compilers that claim to be fully compliant
with the ANSI/ISO C 89/90 language standard.

The only C compiler that comes close is the Comeau compiler:

http://www.comeaucomputing.com/

All C compilers come with a disclaimer
something like the one that came with my GNU C compiler:

GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
See the GNU General Public License for more details.

Do you know of any C compiler that *does* claim to comply
with the ANSI/ISO C 89/90 standard?

This is the legalese problem. If you claim to be ANSI-conforming, and fail
in one particular little area, but for some reason this causes consequential
losses, you can be sued for millions. So the custom has grown up in software
circles of disclaiming fitness "for any particular purpose".
Of course if a program wasn't fit for a particular purpose, then no-one
would buy it. On the other hand I can quite understand Microsoft not wanting
to compensate me for the inconvenience when Windows crashes taking with it
half a day's work.

[Arthur J. O'Dwyer]

On Sun, 29 Aug 2004, Ben Pfaff wrote:

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

Instead we had a lot of feature of dubious use which require rewrites of the
compiler. For instance variables can now be declared anywhere, which seems
to be just a way of making code less organised and harder to read, [...]

I disagree. Declaring a variable in mid-block is a valuable way
to reduce the scope of that variable, giving the programmer less
time to screw it up. Furthermore, a variable declared in
mid-block can usually be initialized in the declaration, which
means there's a bigger chance it can be marked `const', which in
turn gives the programmer less to screw up.

I would agree with you [Ben] if there were some intuitive mechanism
in C99 for /closing/ the scope of a variable with a minimum of clutter.
That is, a lot of the time I want to write the equivalent of:

int foo, baz;
process(foo, baz);
{ /* scope opens */
int bar = 2*foo+1;
process2(bar);
} /* scope closes */
process(baz, foo);

The above code is valid C90 and C99, but it's ugly (IMHO) because
the braces and indentation don't actually represent any control
structure.
C99 fixes /half/ of the problem by letting me write

int foo, baz;
process(foo, baz);
int bar = 2*foo+1; /* scope opens */
process2(bar);
process(baz, foo);

but now, as I said, the problem is that there's no way to "close" the
scope of 'bar' where I intend. 'bar' can be destroyed (by the computer)
and forgotten about (by the reader) once we get to line 5; unfortunately,
there's no way to tell the reader that. And in a long function, the
mental clutter of so many "scope-unclosed" temporary variables can really
impede understanding. ("Okay, here he's defining 'bar'. And he uses it
on the next line... and nowhere else? That can't be right... grep grep...
okay, I guess that is right. Now where was I?")

At least, that's what I find. YMMV.

-Arthur

[CBFalconer]

Ben Pfaff wrote:

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

Instead we had a lot of feature of dubious use which require
rewrites of the compiler. For instance variables can now be
declared anywhere, which seems to be just a way of making code
less organised and harder to read, [...]

I disagree. Declaring a variable in mid-block is a valuable way
to reduce the scope of that variable, giving the programmer less
time to screw it up. Furthermore, a variable declared in
mid-block can usually be initialized in the declaration, which
means there's a bigger chance it can be marked `const', which in
turn gives the programmer less to screw up.

To me it is completely unnecessary. The proper answer is to saw
off the block in question and create a new function. Once in a
blue moon you will run into efficiency considerations, but we are
not supposed to be worrying about that here.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

Ben Pfaff wrote:

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

Instead we had a lot of feature of dubious use which require
rewrites of the compiler. For instance variables can now be
declared anywhere, which seems to be just a way of making code
less organised and harder to read, [...]

I disagree. Declaring a variable in mid-block is a valuable way
to reduce the scope of that variable, giving the programmer less
time to screw it up. Furthermore, a variable declared in
mid-block can usually be initialized in the declaration, which
means there's a bigger chance it can be marked `const', which in
turn gives the programmer less to screw up.

To me it is completely unnecessary. The proper answer is to saw
off the block in question and create a new function. Once in a
blue moon you will run into efficiency considerations, but we are
not supposed to be worrying about that here.

A much more lightweight approach is to create a new block, not a new
function.

For example:

void foo(void)
{
int x;
statement;
int y;
statement;
}

is equivalent to:

void foo(void)
{
int x;
some_statements;
{
int y;
more_statements;
}
}

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

[E. Robert Tisdale]

Flash Gordon wrote:

E. Robert Tisdale wrote:

Robert Gamble wrote:

"GCC supports three versions of the C standard,
although support for the most recent version is not yet complete."
Can you give us a pointer (URL) for this quote?

http://gcc.gnu.org/onlinedocs/gcc-3....html#Standards

Also
http://gcc.gnu.org/onlinedocs/gcc-3....Implementation
for required documentation on implementation defined behaviour.

For information about the library read
http://gcc.gnu.org/onlinedocs/gcc-3....rd%20Libraries

Taking these three things together you have a claim for C89 compliance
on Linux and C95 compliance on Linux.

From the man page of the compiler that is part of the development system
for SCO (spit) Openserver 5.0.7 we have
"For example, to request the complete and strict ANSI C environment,
you can use the option combination -Xc -a ansi".
I can't be bothered to track down the full documentation.

The C compiler by Texas Instruments I used a few years ago for the
TMS320C25 also claimed C89 conformance, obviously as a freestanding
implementation. It mentions ANSI compliance for the latest tools in
http://focus.ti.com/lit/ug/spru376a/spru376a.pdf
I don't have the full documentation as I no longer do embedded development.

I could probably go on finding C compilers claiming ANSI/ISO compliance
either from memory or hunting the web,

No. If there are any other C compilers
which make ANSI/ISO C 89/90 compliance claims,
other subscribers will let us know.
but I've made the point.

You have made your point. I agree that
"provides support for" can be interpreted by a reasonable person
as a claim of "compliance with" the ANSI/ISO standards.
I should also point out that it is a *vacuous* claim
when accompanied by a disclaimer
like the one that comes with your GNU C compiler.

I have never heard of a case where the ANSI or ISO
has accused a compiler vendor of claiming compliance
with the ANSI/ISO C 89/90 standard without actually complying.

[Minti]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi**********************************@unix48.a ndrew.cmu.edu...

On Sun, 29 Aug 2004, Ben Pfaff wrote:

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

Instead we had a lot of feature of dubious use which require rewrites of the compiler. For instance variables can now be declared anywhere, which seems to be just a way of making code less organised and harder to read,

[...]
I disagree. Declaring a variable in mid-block is a valuable way
to reduce the scope of that variable, giving the programmer less
time to screw it up. Furthermore, a variable declared in
mid-block can usually be initialized in the declaration, which
means there's a bigger chance it can be marked `const', which in
turn gives the programmer less to screw up.

I would agree with you [Ben] if there were some intuitive mechanism
in C99 for /closing/ the scope of a variable with a minimum of clutter.
That is, a lot of the time I want to write the equivalent of:

int foo, baz;
process(foo, baz);
{ /* scope opens */
int bar = 2*foo+1;
process2(bar);
} /* scope closes */
process(baz, foo);

The above code is valid C90 and C99, but it's ugly (IMHO) because
the braces and indentation don't actually represent any control
structure.
C99 fixes /half/ of the problem by letting me write

int foo, baz;
process(foo, baz);
int bar = 2*foo+1; /* scope opens */
process2(bar);
process(baz, foo);

but now, as I said, the problem is that there's no way to "close" the
scope of 'bar' where I intend. 'bar' can be destroyed (by the computer)
and forgotten about (by the reader) once we get to line 5; unfortunately,
there's no way to tell the reader that. And in a long function, the
mental clutter of so many "scope-unclosed" temporary variables can really
impede understanding. ("Okay, here he's defining 'bar'. And he uses it
on the next line... and nowhere else? That can't be right... grep grep...
okay, I guess that is right. Now where was I?")

At least, that's what I find. YMMV.

Do you have any suggestions that this may be avoided. I really don't know if
any language does indeed provide the ability to delete/destroy "automatic"
variables. Maybe you could solve the probem using pointers. But then again
YMMV.
--
Imanpreet Singh Arora
"ISINGH AT ACM DOT ORG"

[Mike Sullivan]

E. Robert Tisdale wrote:

All C compilers come with a disclaimer
something like the one that came with my GNU C compiler:

GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.

Do you know of any C compiler that *does* claim to comply
with the ANSI/ISO C 89/90 standard?

That disclaimer is based on sections 11 and 12 of the GNU General Public
License. It is included with all GNU software, and applies to all GPL
licensed software, including Emacs and the Linux kernel.

[Mike Sullivan]

> All C compilers come with a disclaimer

something like the one that came with my GNU C compiler:

GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.

That disclaimer is based on sections 11 and 12 of the GNU General Public
License. It is included with all GNU software, and applies to all GPL
licensed software, including the Linux kernel. It's not there because
GCC isn't C89 compliant.

[Mike Sullivan]

E. Robert Tisdale wrote:

All C compilers come with a disclaimer
something like the one that came with my GNU C compiler:

GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.

That disclaimer is based on sections 11 and 12 of the GNU General Public
License. It is included with all GNU software, and applies to all GPL
licensed software, including the Linux kernel. It's not there because
GCC isn't C89 compliant.

[Eric Sosman]

Mike Wahler wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cg**********@nntp1.jpl.nasa.gov...

I think that the C 99 standard is
"backward compatible" with the C 89 standard

Nope.

so C 89 code is. by definition, "C99-conforming code".

The following conforms to C89 but not C99:

main()
{
return 0;
}

And for completeness, the following conforms to
C99 but not to C89:

int main(void) {}

--
Er*********@sun.com

[Eric Sosman]

Malcolm wrote:

"Mike Wahler" <mk******@mkwahler.net> wrote

You're implying that not using the 'latest and greatest'
tools, simply because they exist, is somehow 'backsliding'.
That's utter nonsense.

The difference is that C99 was designed by a standards body.

... and C89 was designed by ____? I'm having trouble
understanding the distinction.
There is no
point in having a "standard" that is not widely implemented. So the present
situation is very undesireable, but it is largely ANSI's fault,

What did ANSI have to do with C99, other than to adopt the
already-approved ISO standard as an ANSI standard? Are you
arguing that ANSI should have rejected the ISO standard, and
perhaps developed a divergent version?

"The nice thing about standards is that there are so many
of them to choose from." -- Andrew Tanenbaum

--
Er*********@sun.com

[Alan Balmer]

On Sat, 28 Aug 2004 00:44:31 GMT, CBFalconer <cb********@yahoo.com>
wrote:

Richard Tobin wrote:

E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

I have access to a wide variety of different platforms here at
JPL and they all have pretty good C 99 compilers.
If JPL pays me to write some C code for them, I'll bear it in
mind.

I doubt that there's much danger of that happening. Although I've
never figured out what it is they do pay him for.
Considering the normal accuracy of his comments, I have grave
doubts. You will note he fails to specify the compilers involved,
which makes this just another Trollsdale troll.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Dan Pop]

In <41**************@sun.com> Eric Sosman <Er*********@sun.com> writes:

And for completeness, the following conforms to
C99 but not to C89:

int main(void) {}

Huh?!?

Does it require a diagnostic in C89? Chapter and verse.
Does it invoke undefined behaviour in C89? Chapter and verse.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Eric Sosman]

Dan Pop wrote:

In <41**************@sun.com> Eric Sosman <Er*********@sun.com> writes:

And for completeness, the following conforms to
C99 but not to C89:

int main(void) {}

Huh?!?

Does it require a diagnostic in C89? Chapter and verse.

No; undefined behavior does not require a diagnostic.
1.6 "Definitions of terms".
Does it invoke undefined behaviour in C89? Chapter and verse.

Yes. 3.6.6.4 "The return statement" says that reaching
a function's closing } is equivalent to executing a return
with no value. 2.1.2.2 "Hosted environment" says that if the
initial invocation of main() executes a return with no value,
the status returned to the host environment is undefined.
1.6 "Definitions of terms" says that using an indeterminately
valued object produces undefined behavior.

If you can argue that the host environment's use of the
termination status isn't a "use," you can probably get along
well with Bill Clinton.

--
Er*********@sun.com

[Mabden]

"Alan Balmer" <al******@att.net> wrote in message
news:hi********************************@4ax.com...

On Sat, 28 Aug 2004 00:44:31 GMT, CBFalconer <cb********@yahoo.com>
wrote:

Richard Tobin wrote:

E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

I have access to a wide variety of different platforms here at
JPL and they all have pretty good C 99 compilers.

If JPL pays me to write some C code for them, I'll bear it in
mind.

I doubt that there's much danger of that happening. Although I've
never figured out what it is they do pay him for.

Considering the normal accuracy of his comments, I have grave
doubts. You will note he fails to specify the compilers involved,
which makes this just another Trollsdale troll.

Oh boy, I get to read another "E. Robert Tisdale" is a troll message.

Q. When does pointing out a troll become trolling?
A. Last year.

Everyone knows that statements made on the Internet should be taken with a
grain of salt. M'kay. Get over it. I can find the kill button all by myself,
so STFU.

--
Mabden

[Michael Wojcik]

In article <2p************@uni-berlin.de>, "Minti" <mi************@yahoo.com> writes:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi**********************************@unix48.a ndrew.cmu.edu...

C99 fixes /half/ of the problem by letting me write

int foo, baz;
process(foo, baz);
int bar = 2*foo+1; /* scope opens */
process2(bar);
process(baz, foo);

but now, as I said, the problem is that there's no way to "close" the
scope of 'bar' where I intend. 'bar' can be destroyed (by the computer)
and forgotten about (by the reader) once we get to line 5; unfortunately,
there's no way to tell the reader that.
Do you have any suggestions that this may be avoided.

As Arthur already noted, it can be avoided in any version of C from
C89 on by creating a block. He finds that aesthetically unpleasing,
but I, for one, do not, and you can make your own decision.
I really don't know if
any language does indeed provide the ability to delete/destroy "automatic"
variables.

LISP does, for one, if I understand what you're describing.

--
Michael Wojcik mi************@microfocus.com

I do not care to listen; obloquy injures my self-esteem and I am
skeptical of praise. -- Jack Vance

[CBFalconer]

Mabden wrote:

.... snip ...
Oh boy, I get to read another "E. Robert Tisdale" is a troll
message.

Q. When does pointing out a troll become trolling?
A. Last year.

Everyone knows that statements made on the Internet should be
taken with a grain of salt. M'kay. Get over it. I can find the
kill button all by myself, so STFU.

Unfortunately (or fortunately) there are always newbies appearing
here. Without periodic warnings they would have no idea who
should be listened to and who should not. You may note that not
all of his postings are so marked, because he does occasionally
say something that is not in error.

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR

[E. Robert Tisdale]

Malcolm wrote:

The difference is that C99 was designed by a standards body.
There is no point in having a "standard" that is not widely implemented.
So the present situation is very undesireable, but it is largely ANSI's fault,
because the extensions were neither so minimal that they could be
trivially implemented (a #define for bool, a vnsprintf() function, etc)
nor were like the C++ extensions,
very far reaching and offering greatly enhanced functionality.
Instead, we had a lot of feature of dubious use
which require rewrites of the compiler.
For instance, variables can now be declared anywhere which seems to be
just a way of making code less organised and harder to read,
and variable arrays are allowed.
Since a variable length array cannot fail,
and the programmer won't know the array length at run time,
this is asking for a security exploit.

Your indictment of ANSI seems to imply that
it is taking a lot longer for C compiler developers to implement
the C99 standard than it took to implement the C89 standard
and that the blame for the delay belongs [mostly] with ANSI
and *not* with the C compiler developers.

[Arthur J. O'Dwyer]

On Sat, 28 Aug 2004, Malcolm wrote:
[...]

variable arrays are allowed. Since a variable length array cannot fail,
and the programmer won't know the array length at run time, this is
asking for a security exploit. ^^^^^^^^^^^

Nit: ITYM "at compile time."

I just checked N869, and I don't see any provision for the failure
of VLA allocation either. Does that mean that if the programmer writes

#include <stdlib.h>
int main(int argc, char **argv)
{
int foo[atoi(argv[1])];
}

that will simply invoke undefined behavior if the user enters, say,
'./a.out 1000000' and there's not enough memory to satisfy such a
request?

That does seem like a weird "feature" to add to C99, then, if it
can just fail randomly with no chance of recovery! :(

[xpost to c.s.c added]

-Arthur

[Mabden]

"CBFalconer" <cb********@yahoo.com> wrote in message
news:41***************@yahoo.com...

Mabden wrote:

Everyone knows that statements made on the Internet should be
taken with a grain of salt. M'kay. Get over it. I can find the
kill button all by myself, so STFU.
Unfortunately (or fortunately) there are always newbies appearing
here. Without periodic warnings they would have no idea who
should be listened to and who should not.

You may note that not all of his postings are so marked,
because he does occasionally
say something that is not in error.

How benign. Praise you.

I have seen more garbage disposing him (to coin a phrase) than any kind of
erroneous posts and numerous harping on a slight misspelling or nuance that
does not detract from the actual point he was making - just to then add "is
a known troll" - is not helpful to the discussion so why are you "helping".
It has gotten really old, since I find no problem with the post in question,
only with the (mandatory) follow-up posts. Take a breath and google some
responses in the last 3 months. They have no content at all. Just a warning
about trolls. People understand (or come to understand) that the Internet is
an open forum and any maniac may post. Little girls will be seduced, people
will be electrocuted, dogs will be badly trained - all by following advice
from the Internet.

Sorry for the rant, but I am tired of the follow-ons and if you continue it
you will also find the tedium of my follow-ons saying please stop. Of course
there are many of you and only one of me, so I am easier to killfile.
Hmmmm... I will have to think about this.

But please stop. People are able to decide who to listen to, and one person
will not the world change. Or change the world, but it sounded cooler in my
head the other way.

--
Mabden
"Changing the world, one post at a time."

[Jack Klein]

On Mon, 30 Aug 2004 19:35:50 -0400 (EDT), "Arthur J. O'Dwyer"
<aj*@nospam.andrew.cmu.edu> wrote in comp.std.c:

On Sat, 28 Aug 2004, Malcolm wrote:
[...]

variable arrays are allowed. Since a variable length array cannot fail,
and the programmer won't know the array length at run time, this is
asking for a security exploit. ^^^^^^^^^^^

Nit: ITYM "at compile time."

I just checked N869, and I don't see any provision for the failure
of VLA allocation either. Does that mean that if the programmer writes

#include <stdlib.h>
int main(int argc, char **argv)
{
int foo[atoi(argv[1])];
}

that will simply invoke undefined behavior if the user enters, say,
'./a.out 1000000' and there's not enough memory to satisfy such a
request?

That does seem like a weird "feature" to add to C99, then, if it
can just fail randomly with no chance of recovery! :(

[xpost to c.s.c added]

Why so strange? This program can fail:

#include <stdio.h>
int main(void)
{
int foo [1000000];
foo [999999] = 42;
printf("%d\n", 42);
}

Since an array of one million ints has a size greater than 65,535
bytes, no implementation is required to successfully translate and
execute it.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Douglas A. Gwyn]

Arthur J. O'Dwyer wrote:

int foo[atoi(argv[1])];

It's essentially like any other kind of potential
stack overflow, and what occurs upon such overflow
is beyond the scope of the standard.

Malcolm's criticisms (which I saw only embedded in
a later response) were off the mark.

[Dan Pop]

In <41**************@sun.com> Eric Sosman <Er*********@sun.com> writes:

Dan Pop wrote:

In <41**************@sun.com> Eric Sosman <Er*********@sun.com> writes:

And for completeness, the following conforms to
C99 but not to C89:

int main(void) {}

Huh?!?

Does it require a diagnostic in C89? Chapter and verse.

No; undefined behavior does not require a diagnostic.
1.6 "Definitions of terms".

Does it invoke undefined behaviour in C89? Chapter and verse.

Yes. 3.6.6.4 "The return statement" says that reaching
a function's closing } is equivalent to executing a return
with no value. 2.1.2.2 "Hosted environment" says that if the
initial invocation of main() executes a return with no value,
the status returned to the host environment is undefined.
1.6 "Definitions of terms" says that using an indeterminately
valued object produces undefined behavior.

If the indeterminately valued object is used *by the C program*.
If you can argue that the host environment's use of the
termination status isn't a "use," you can probably get along
well with Bill Clinton.

1. The termination status is not a C object. It's not even a value with
a C type.

2. Since this use of the termination status is outside of the execution
of the C program (the execution of the C program has terminated by
then), the text of the C standard does not apply to it: it is beyond
the scope of the C standard.

Before being sarcastic, make sure that your brain is fully engaged ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Alan Balmer]

On Tue, 31 Aug 2004 00:43:48 GMT, "Mabden" <mabden@sbc_global.net>
wrote:

But please stop. People are able to decide who to listen to, and one person
will not the world change.

Yes, you are free to read or not read any post here, as are the rest
of us. If you find the writings of any particular person too obnoxious
or tedious, you can killfile them, as I have long ago killfiled Mr.
Tisdale. I am on the verge of finding your writings tedious, as well.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Michael Wojcik]

In article <8R******************@newssvr27.news.prodigy.com >, "Mabden" <mabden@sbc_global.net> writes:

"CBFalconer" <cb********@yahoo.com> wrote in message
news:41***************@yahoo.com...

Unfortunately (or fortunately) there are always newbies appearing
here. Without periodic warnings they would have no idea who
should be listened to and who should not.
But please stop.

In this matter you appear to be in the minority of posters to c.l.c
who have expressed an opinion; that being the case, I imagine you'll
have to come up with a stronger argument than "I don't like it".
People are able to decide who to listen to,

Yes. However, they have historically not been able to make that
decision well, absent any information about the person speaking.
Have people suddenly gained a magic ability to unerringly determine
the value of someone else's statements? I must have missed that.

Usenet is by its nature an antagonistic forum; it does not lend
itself to the gradual building of consensus. (Read some of the
academic work on discourse in this sort of environment if you're
curious why.) Public response is the only direct mechanism available
for vetting the ideas presented in unmoderated newsgroups. Asking
people to refrain from making such responses is tantamount to asking
them to reduce the information content of the group.

--
Michael Wojcik mi************@microfocus.com

_
| 1
| _______ d(cabin) = log cabin + c = houseboat
| (cabin)
_| -- Thomas Pynchon

[Mabden]

"Michael Wojcik" <mw*****@newsguy.com> wrote in message
news:ch*********@news2.newsguy.com...

In article <8R******************@newssvr27.news.prodigy.com >, "Mabden"

<mabden@sbc_global.net> writes:

"CBFalconer" <cb********@yahoo.com> wrote in message
news:41***************@yahoo.com...

Unfortunately (or fortunately) there are always newbies appearing
here. Without periodic warnings they would have no idea who
should be listened to and who should not.

But please stop.

In this matter you appear to be in the minority of posters to c.l.c
who have expressed an opinion; that being the case, I imagine you'll
have to come up with a stronger argument than "I don't like it".

People are able to decide who to listen to,

Yes. However, they have historically not been able to make that
decision well, absent any information about the person speaking.
Have people suddenly gained a magic ability to unerringly determine
the value of someone else's statements? I must have missed that.

Usenet is by its nature an antagonistic forum; it does not lend
itself to the gradual building of consensus. (Read some of the
academic work on discourse in this sort of environment if you're
curious why.) Public response is the only direct mechanism available
for vetting the ideas presented in unmoderated newsgroups. Asking
people to refrain from making such responses is tantamount to asking
them to reduce the information content of the group.

Understood, but I feel like I'm in a Monty Python skit at this point.
"An argument is a connected series of statements intended to establish a
proposition. It's not just saying, 'No it isn't.'"
"Yes it is."
"No, it isn't"

When some one makes a remark on the usenet it may be correct, it may be
false, it may be somewhere in between. You are free to correct the poster,
or ignore the error. But to just post to say, "This guy is a shithead" isn't
helpful. The messages I'm objecting to have no instructive or constructive
content other than "that guy is a shithead and everyone already knows it, so
I want to be first to say it again".

Just killfile him and YOU won't have to hear what he has to say, and the
rest of us can go on listening to whomever we choose.

Now, unfortunately for me, I don't wish to killfile the posters doing it
like CBF, yourself, etc. because they tend to have good comments once in a
while and that's why I read here. But they have this one-sided fight that
seems a little unreasonable to the casual reader of this newsgroup. Perhaps
ERT has mollified (does that mean lightened-up?) in his bad behaviour but he
really hasn't said anything trollish in the last 6 months that I have been
here.

Anyone (including yours truly) can be mistaken and pedantic about a point
they believe correct, and I believe I was called troll in one thread with
another gentleman. I learned a lesson about C through the conversation,
however, and there was no trolling going on, simply extensive requests for
clarification that ended in my enlightenment. So I have felt the sting of
the troll brush, and will probably feel it again for responding to this
post. That or a sock-puppet card. In any case, I am merely stating again,
for anyone still reading, that I don't find any recent posts by ERT to
display any trolling or inappropriate language, but I have seen such
behaviour in those following along behind him issuing harassing missives
behind his back EVERY TIME. That is a troll.

Killfile me if you want, but please killfile ERT first so I don't have to
read your flames about him anymore.

--
Mabden