C 99 compiler access

[Flash Gordon]

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

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

Also
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/C-Implementation.html#C Implementation
for required documentation on implementation defined behaviour.

For information about the library read
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/Standard-Libraries.html#Standard Libraries

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.

 

[Richard Tobin]

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

[/QUOTE]

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]

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.

 

[Ben Pfaff]

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.

 

[Arthur J. O'Dwyer]

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

 

[Malcolm]

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.

 

[Minti]

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.

 

[CBFalconer]

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.

 

[Keith Thompson]

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;
}
}

 

[E. Robert Tisdale]

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

Also
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/C-Implementation.html#C Implementation
for required documentation on implementation defined behaviour.

For information about the library read
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/Standard-Libraries.html#Standard Libraries

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.

 

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

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]

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]

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) {}

 

[Eric Sosman]

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

 

[Dan Pop]

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

 

[Alan Balmer]

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

 

[Eric Sosman]

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.

 

[Michael Wojcik]

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.

 

[Mabden]

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

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.