Hi All
What is C99 Standard is all about. is it portable, i mean i saw
-std=C99 option in GCC
but there is no such thing in VC++.?
which one is better ANSI C / C99?
can i know the major difference between C99 & ANSI C standards?
83  11514 
sunny said:
Hi All
What is C99 Standard is all about.
It's the replacement to C, and popular implementations might be porting to
C99 Any Decade Now.
is it portable,
No. Some compilers implement some bits of it. Other compiler implement other
bits. Some implement some bits of it /wrong/ (or, at least, differently to
what C99 requires, perhaps through bugginess or ignorance, but possibly for
good reasons of their own). Some compilers don't implement any of it. And a
handful of (not so well-known) compilers implement it all.
i mean i saw
-std=C99 option in GCC
It's a misnomer. What it means is "the bits of C99 which we can be bothered
to implement" (which, to be fair, is quite a lot of it). But not all gcc
versions have a -std=C99 option. Mine, for instance, does not.
but there is no such thing in VC++.?
Right. Microsoft are not actively seeking to support C99.
which one is better ANSI C / C99?
That depends on what you mean by "better".
can i know the major difference between C99 & ANSI C standards?
http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html
--
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)
sunny wrote:
Hi All
What is C99 Standard is all about.
It is the current C standard, as defined by ANSI/ISO. The old standard
(C89) is now obsolete.
is it portable
Yes. There are compilers for it under linux, windows, and many
other operating systems and implementations. Microsoft doesn't
implement it, but you can find compilers like intel compiler
that implements it. Comeau C/C++ implements C99 also.
, i mean i saw
-std=C99 option in GCC
but there is no such thing in VC++.?
VC++ doesn't care about C development and has abandonend
most C development to concentrate on C# C++ and other languages.
>
which one is better ANSI C / C99?
C99 offers most of the all standard (including warts like gets())
and adds significant functionality.
can i know the major difference between C99 & ANSI C standards?
http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html
jacob navia said:
sunny wrote:
>Hi All
What is C99 Standard is all about.
It is the current C standard, as defined by ANSI/ISO. The old standard
(C89) is now obsolete.
Merriam-Webster defines "obsolete" as "no longer in use or no longer
useful", which is certainly not true of C89. It also offers "of a kind or
style no longer current", which again is not true of C89.
is it portable
Yes.
Provided you are prepared to spend money replacing your C90 compilers with
newer versions, and provided you aren't too picky about which platforms you
want to port to.
There are compilers for it under linux, windows, and many
other operating systems and implementations.
How about OS390? VM/CMS? UNICOS? SHARC?
Microsoft doesn't implement it,
So it is effectively non-portable, since a great many C programmers are
required to use the compiler supplied by their employer, and for a great
many employers, Microsoft is the preferred supplier for Windows-based
development software.
<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)
sunny wrote:
Hi All
What is C99 Standard is all about.
It takes a long time for standards to become widely adopted in the field.
is it portable
It is portable among systems implementing the standard, if you can find
any.
i mean i saw
-std=C99 option in GCC
GCC is working towards C99 conformance, but it's not complete.
but there is no such thing in VC++.?
And Microsoft reports having no plans to implement this standard.
which one is better ANSI C / C99?
Which one is better, ketchup or mustard?
can i know the major difference between C99 & ANSI C standards?
What qualifies as "major" is a matter of opinion. Some important
differences
.. Identifiers have increased significant length
.. "//" style comments are allowed
.. Variable arguments in macros
.. Inline functions
.. Restricted pointers (can be "restricted" from pointing to the same
object.)
.. a _Bool type
.. Vars can be declared anywhere in a block
.. Functions no longer return 'int' by default
.. Last data member of a struct can be an array of unspecified size
.. Complex number type
.. Repeated type qualifier is folded into a single qualifier. (Though a
special case is made for "long long" which provides a 64 bit integer type.
The "restricted pointer" (two pointers cannot reference the same memory
address) allows compiler implementors to perform certain optimizations: http://www.accu.informika.ru/accu/ev...lic/c_news.htm
Complex (and a distinct "Imaginary") type will have applications in
signal processing and number-theoretic algorithms. With Complex numbers
being a language feature, implementations may be able to optimize
arithmetic operations, so that for instance, library calls will not be
necessary for arithmetic.
Some of these standards are already de-facto standards in many systems,
like "//" comments, long identifiers, inline functions, 64-bit "long
long", incomplete array in a struct.
Some are no doubt going to lead to more obfuscation opportunities.
Vararg macros? I can see very useful application for that, but I can
see more potential for abuse.
Read "The Rationale for the C99 Standard" http://std.dkuug.dk/JTC1/SC22/WG14/w...onaleV5.10.pdf
jmcgill said:
sunny wrote:
>Hi All
What is C99 Standard is all about.
It takes a long time for standards to become widely adopted in the field.
>is it portable
It is portable among systems implementing the standard, if you can find
any.
Beautifully put.
>i mean i saw
-std=C99 option in GCC
GCC is working towards C99 conformance, but it's not complete.
When was the last change to GCC that increased its C99 conformance?
(I'm guessing four or five years ago, but I'll be glad to be proved wrong.
It would be nice to know they're at least still having a crack at it...)
<snip>
>which one is better ANSI C / C99?
Which one is better, ketchup or mustard?
Ketchup. No, mustard! Er, ketc...must...ke... mu.
--
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)
jmcgill wrote:
sunny wrote:
>>Hi All
What is C99 Standard is all about.
It takes a long time for standards to become widely adopted in the field.
>>is it portable
It is portable among systems implementing the standard, if you can find
any.
I find linux and windows are quite a big part of
the workstation market.
jacob navia wrote:
I find linux and windows are quite a big part of
the workstation market.
Linux and Windows having what, exactly, to do with the C99 standard?
jmcgill wrote:
jacob navia wrote:
>>I find linux and windows are quite a big part of
the workstation market.
Linux and Windows having what, exactly, to do with the C99 standard?
because you said:
It is portable among systems implementing the standard, if you can find
any.
I found two
jacob navia wrote:
jmcgill wrote:
>jacob navia wrote:
>>I find linux and windows are quite a big part of
the workstation market.
Linux and Windows having what, exactly, to do with the C99 standard?
because you said:
It is portable among systems implementing the standard, if you can find
any.
I found two
Neither "windows" nor "linux" is a C99 compiler or runtime library, so I
really have no idea what you are trying to claim.
jmcgill wrote:
jacob navia wrote:
>>jmcgill wrote:
>>>jacob navia wrote:
I find linux and windows are quite a big part of
the workstation market.
Linux and Windows having what, exactly, to do with the C99 standard?
because you said:
It is portable among systems implementing the standard, if you can find
any.
I found two
Neither "windows" nor "linux" is a C99 compiler or runtime library, so I
really have no idea what you are trying to claim.
Excuse me, I misunderstood "system" as operating system.
Actually, it looks that you meant "compiler system". Well,
my answer stays, gcc implements C99 under unix, and under windows
there is intel compiler, lcc-win32 and Comeau, that actually
also runs under Unix.
That makes for more than two "compiler systems"
jacob
jacob navia wrote:
jmcgill wrote:
>jacob navia wrote:
>>jmcgill wrote:
jacob navia wrote:
I find linux and windows are quite a big part of
the workstation market.
Linux and Windows having what, exactly, to do with the C99 standard?
because you said:
It is portable among systems implementing the standard, if you can find
any.
I found two
Neither "windows" nor "linux" is a C99 compiler or runtime library, so I
really have no idea what you are trying to claim.
Excuse me, I misunderstood "system" as operating system.
Actually, it looks that you meant "compiler system". Well,
my answer stays, gcc implements C99 under unix, and under windows
there is intel compiler, lcc-win32 and Comeau, that actually
also runs under Unix.
That makes for more than two "compiler systems"
There are some important features of C99 that are not yet implemented by
GCC. Comeau does not have a runtime library, but Dinkumware+Comeau
solves that problem. There is an IBM compiler that you do not mention,
which is said to be a complete C99 implementation.
If you are willing to consider GCC4.x as a C99 compiler despite its
limitations, then there is a long, long list of target platforms that
support it.
I suspected your messages were just an effort to be contrary.
jmcgill wrote:
>
I suspected your messages were just an effort to be contrary.
No, it is because hearthfield took
"if you can find them" as an ironic way of saying
"almost none exists"
I am aware that the refusal by microsoft of accepting
c99 is a BIG stumbling block, but nevertheless, there
are many compiler that support it.
jacob
jacob navia said:
<snip>
Actually, it looks that you meant "compiler system". Well,
my answer stays, gcc implements C99 under unix,
No, it doesn't. There is no fully C99-conforming version of gcc at present.
and under windows there is intel compiler,
Got a URL? All I could find on their site were C++ compilers.
lcc-win32
Given the maintainer's limited knowledge of C as evidenced in comp.lang.c, I
must say I entertain certain doubts about whether lcc-win32 is
C99-conforming in all respects.
and Comeau, that actually also runs under Unix.
Certainly true, but "it also supports many of the C99 features provided by
this new revised ISO Standard for C" - which indicates that it is not in
fact C99-conforming in all respects.
That makes for more than two "compiler systems"
No, it doesn't.
--
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)
jacob navia wrote:
there
are many compiler that support it.
's/many/a few/'; 's/support it/support it to varying degrees/'
Richard Heathfield wrote:
jacob navia said:
and under windows there is intel compiler,
Got a URL? All I could find on their site were C++ compilers.
The "Intel C++ Compiler" is a less than perfect name; ICC includes
separate C and C++ compilers. I don't know if it's a conforming
implementation, though; from their own site: http://www.intel.com/support/perform.../cs-015003.htm
C Standard Conformance
The Intel® C++ Compilers provide some conformance to the ANSI/ISO
standard for C language compilation (ISO/IEC 9899:1999).
For more information on C conformance, refer to the User's Guide.
"Some conformance" ? (In fairness though, I don't know of any issues
icc may have that would make it nonconforming.)
Harald van Dijk wrote:
Richard Heathfield wrote:
>>jacob navia said:
>>>and under windows there is intel compiler,
Got a URL? All I could find on their site were C++ compilers.
The "Intel C++ Compiler" is a less than perfect name; ICC includes
separate C and C++ compilers. I don't know if it's a conforming
implementation, though; from their own site:
http://www.intel.com/support/perform.../cs-015003.htm
C Standard Conformance
The Intel® C++ Compilers provide some conformance to the ANSI/ISO
standard for C language compilation (ISO/IEC 9899:1999).
For more information on C conformance, refer to the User's Guide.
"Some conformance" ? (In fairness though, I don't know of any issues
icc may have that would make it nonconforming.)
It is business talk.
If you write
This is 100% conforming you are liable if there is the
slightest bug. If you write "some" conformance, you are
not.
Richard Heathfield wrote:
jacob navia said:
<snip>
>>Actually, it looks that you meant "compiler system". Well,
my answer stays, gcc implements C99 under unix,
No, it doesn't. There is no fully C99-conforming version of gcc at present.
>>and under windows there is intel compiler,
Got a URL? All I could find on their site were C++ compilers.
>>lcc-win32
Given the maintainer's limited knowledge of C as evidenced in comp.lang.c, I
must say I entertain certain doubts about whether lcc-win32 is
C99-conforming in all respects.
Given the history of pedantic remarks you use,
it is obvious that you can't refrain.
But if you want it, you are right.
I have "a limited knowledge of C". I am not "the GURU",
and I do make mistakes.
Other people, think that they have "unlimited knowledge
of C", they know everything.
I am not that kind of person.
jacob navia wrote:
Harald van Dijk wrote:
Richard Heathfield wrote:
>jacob navia said:
and under windows there is intel compiler,
Got a URL? All I could find on their site were C++ compilers.
The "Intel C++ Compiler" is a less than perfect name; ICC includes
separate C and C++ compilers. I don't know if it's a conforming
implementation, though; from their own site:
http://www.intel.com/support/perform.../cs-015003.htm
C Standard Conformance
The Intel® C++ Compilers provide some conformance to the ANSI/ISO
standard for C language compilation (ISO/IEC 9899:1999).
For more information on C conformance, refer to the User's Guide.
"Some conformance" ? (In fairness though, I don't know of any issues
icc may have that would make it nonconforming.)
It is business talk.
If you write
This is 100% conforming you are liable if there is the
slightest bug. If you write "some" conformance, you are
not.
Then explain to me why they do claim full C++ conformance at the very
same page for the Linux version, and only a single issue with C++
conformance for the Windows version.
jacob navia said:
Harald van Dijk wrote:
>>
<snip>
>>
"Some conformance" ? (In fairness though, I don't know of any issues
icc may have that would make it nonconforming.)
It is business talk.
If you write
This is 100% conforming you are liable if there is the
slightest bug. If you write "some" conformance, you are
not.
So what you seem to be saying is that even the people who wrote the compiler
are not convinced it's fully conforming. So why should anyone else be
convinced?
--
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)
jacob navia said:
Richard Heathfield wrote:
>jacob navia said:
<snip>
>>
>>>lcc-win32
Given the maintainer's limited knowledge of C as evidenced in
comp.lang.c, I must say I entertain certain doubts about whether
lcc-win32 is C99-conforming in all respects.
Given the history of pedantic remarks you use,
it is obvious that you can't refrain.
But if you want it, you are right.
So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.
--
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 wrote:
jacob navia said:
Richard Heathfield wrote:
jacob navia said:
<snip>
>
lcc-win32
Given the maintainer's limited knowledge of C as evidenced in
comp.lang.c, I must say I entertain certain doubts about whether
lcc-win32 is C99-conforming in all respects.
Given the history of pedantic remarks you use,
it is obvious that you can't refrain.
But if you want it, you are right.
So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.
You mean one, right? IBM's? It was mentioned in this thread, and from http://www-306.ibm.com/software/awdt...cpp/features/:
"The C and the C++ compilers conform to the latest ISO/IEC
International Standards. The C compiler supports the latest ISO C 1999
(International Standard ISO/IEC 9899:1999) standard, also known as C99."
Harald van Dijk wrote:
Richard Heathfield wrote:
>>jacob navia said:
>>>Richard Heathfield wrote:
jacob navia said:
<snip>
>>>>>lcc-win32
Given the maintainer's limited knowledge of C as evidenced in
comp.lang.c, I must say I entertain certain doubts about whether
lcc-win32 is C99-conforming in all respects.
Given the history of pedantic remarks you use,
it is obvious that you can't refrain.
But if you want it, you are right.
So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.
You mean one, right? IBM's? It was mentioned in this thread, and from
http://www-306.ibm.com/software/awdt...cpp/features/:
"The C and the C++ compilers conform to the latest ISO/IEC
International Standards. The C compiler supports the latest ISO C 1999
(International Standard ISO/IEC 9899:1999) standard, also known as C99."
If you ignore pedantic people, there are MANY more. Intel's, gcc, and
many others are almost 100% conformant. A few irrelevant issues are
a justification fgor pedantic people to scream "NO, there is NONE"
Just ignore them
jacob navia <ja***@jacob.remcomp.frwrites:
sunny wrote:
>Hi All
What is C99 Standard is all about.
It is the current C standard, as defined by ANSI/ISO. The old standard
(C89) is now obsolete.
C89 (or, equivalently, C90) is "obsolete" only in a very narrow and
legalistic sense. The C99 standard *offically* supersedes the C90
standard, but it is not widely implemented. The only reliable way to
produce portable C code is to limit yourself to the C90 standard,
while avoiding incompatibilities with C99 (for example, don't use
"restrict" as an identifier, because it's a keyword in C99 but not in
C90). The resulting code, if written carefully, will work correctly
under both C90 and C99 implementations.
C90 is still widely used and widely supported. C99 (by which I mean
the full language defined by the C99 standard) is not.
jacob, you know this perfectly well.
is it portable
Yes. There are compilers for it under linux, windows, and many
other operating systems and implementations. Microsoft doesn't
implement it, but you can find compilers like intel compiler
that implements it. Comeau C/C++ implements C99 also.
There are a very few compilers that *fully* support C99. Intel's
compiler does not, as far as I know; we discussed this here recently.
[snip]
>which one is better ANSI C / C99?
C99 offers most of the all standard (including warts like gets())
and adds significant functionality.
Significance is in the eye of the beholder. C99 has some nice
features, but none that I can't get along without.
If you insist on using the full C99 language, you're going to have to
avoid using any compilers that don't fully support it. That means you
won't be able to use gcc, any Microsoft compiler, or lcc-win32.
--
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.
jacob navia <ja***@jacob.remcomp.frwrites:
[...]
Excuse me, I misunderstood "system" as operating system.
Actually, it looks that you meant "compiler system". Well,
my answer stays, gcc implements C99 under unix, and under windows
there is intel compiler, lcc-win32 and Comeau, that actually
also runs under Unix.
That makes for more than two "compiler systems"
It does not, as you know perfectly well.
gcc does not fully support C99. See
<http://gcc.gnu.org/c99status.htmlfor details. And of course gcc
uses the operating system's C library, so even if the compiler were
100% C99 compliant, the *implementation* would not be on many systems.
I don't believe that Intel's compiler fully supports C99. If you can
demonstrate that it does, please do so.
When I asked you about lcc-win32's C99 support in comp.compilers.lcc
just a few weeks ago, you wrote:
| No, there isn't a listing but I am implementing as time
| permits.
|
| Designated initializers and structure initializers with the
| dot notation are missing.
|
| I am giving priority to the library, that is kind of
| "mostly" finished. I have probably some problems with
| complex numbers, there hasn't been a good testing of that
| part.
|
| Besides the preprocessor is still missing the variable
| arguments feature.
I don't know Comeau's status, and I've never used it.
So that's *at most* one C implementation that fully supports C99.
I am *astonished* that you would claim that lcc-win32 implements C99,
after having explicitly stated that it does not.
And if you consider a compiler that supports only a *subset* of C99 to
be a "C99 compiler", then every conforming C90 compiler is a C99
compiler; after all, C90 is most of C99.
--
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 wrote:
I don't believe that Intel's compiler fully supports C99. If you can
demonstrate that it does, please do so.
Having just tested it, I can demonstrate that it does not.
$ cat test.c
int main (void)
{
printf ("Hello, world!\n");
}
$ icc --version
icc (ICC) 9.1 20060816
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
$ icc -strict-ansi -c99 -Wall test.c -o test
$ ./test
Hello, world!
(C99 requires a diagnostic for syntax errors, and undeclared
identifiers are a syntax error.)
Keith Thompson posted:
C89 (or, equivalently, C90) is "obsolete" only in a very narrow and
legalistic sense. The C99 standard *offically* supersedes the C90
standard, but it is not widely implemented. The only reliable way to
produce portable C code is to limit yourself to the C90 standard,
while avoiding incompatibilities with C99 (for example, don't use
"restrict" as an identifier, because it's a keyword in C99 but not in
C90). The resulting code, if written carefully, will work correctly
under both C90 and C99 implementations.
I wonder if there are many circumstances in which certain behaviour was
defined by the C89 Standard, but then became undefined by the C99 Standard? I
can think of one instance:
int Func(void) {}
int main(void) { Func(); return 0; }
--
Frederick Gotham
Frederick Gotham wrote:
Keith Thompson posted:
C89 (or, equivalently, C90) is "obsolete" only in a very narrow and
legalistic sense. The C99 standard *offically* supersedes the C90
standard, but it is not widely implemented. The only reliable way to
produce portable C code is to limit yourself to the C90 standard,
while avoiding incompatibilities with C99 (for example, don't use
"restrict" as an identifier, because it's a keyword in C99 but not in
C90). The resulting code, if written carefully, will work correctly
under both C90 and C99 implementations.
I wonder if there are many circumstances in which certain behaviour was
defined by the C89 Standard, but then became undefined by the C99 Standard? I
can think of one instance:
int Func(void) {}
int main(void) { Func(); return 0; }
This is a strictly conforming program in C99.
=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= posted:
>int Func(void) {}
int main(void) { Func(); return 0; }
This is a strictly conforming program in C99.
Over on comp.lang.c++, we were discussing the idea of a non-void-returning
function not having a return statement. One of the participants claimed that
it was UB in C99 because of the following:
(section 6.8.6.4/1,
a constraint on the return statement): "A return statement without an
expression shall appear only in a function whose return type is void."
However, I read that to mean that the following is broken:
int Func(void) { return; }
rather than the following being broken:
int Func(void) {}
--
Frederick Gotham
Harald van D?k said:
Richard Heathfield wrote:
<snip>
>So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.
You mean one, right? IBM's? It was mentioned in this thread,
Oops, must have missed that. Okay, one, then.
And presumably the C99 source code is portable between the IBM compiler
and... er... the IBM compiler. Excellent. Nice one, ISO.
--
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)
jacob navia said:
<snip>
If you ignore pedantic people, there are MANY more. Intel's, gcc, and
many others are almost 100% conformant. A few irrelevant issues are
a justification fgor pedantic people to scream "NO, there is NONE"
Just ignore them
Be very wary of any implementor who thinks pedantry is a Bad Thing.
--
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)
jacob navia <ja***@jacob.remcomp.frwrites:
Harald van Dijk wrote:
>Richard Heathfield wrote:
>>>jacob navia said:
and under windows there is intel compiler,
Got a URL? All I could find on their site were C++ compilers.
The "Intel C++ Compiler" is a less than perfect name; ICC includes
separate C and C++ compilers. I don't know if it's a conforming
implementation, though; from their own site:
http://www.intel.com/support/perform.../cs-015003.htm
C Standard Conformance
The Intel® C++ Compilers provide some conformance to the ANSI/ISO
standard for C language compilation (ISO/IEC 9899:1999).
For more information on C conformance, refer to the User's Guide.
"Some conformance" ? (In fairness though, I don't know of any issues
icc may have that would make it nonconforming.)
It is business talk.
If you write
This is 100% conforming you are liable if there is the
slightest bug. If you write "some" conformance, you are
not.
Or you might write "some conformance" if you know that your compiler
isn't fully conforming.
If you have some actual knowledge about the Intel compiler's C99
conformance, beyond what's on the web page, perhaps you could share it
with the rest of us. Intel's statement of "some conformance"
certainly isn't enough for us to assume that it's fully conforming.
--
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.
jacob navia <ja***@jacob.remcomp.frwrites:
Harald van Dijk wrote:
>Richard Heathfield wrote:
[...]
>>>So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.
You mean one, right? IBM's? It was mentioned in this thread, and from
http://www-306.ibm.com/software/awdt...cpp/features/:
"The C and the C++ compilers conform to the latest ISO/IEC
International Standards. The C compiler supports the latest ISO C 1999
(International Standard ISO/IEC 9899:1999) standard, also known as C99."
If you ignore pedantic people, there are MANY more. Intel's, gcc, and
many others are almost 100% conformant. A few irrelevant issues are
a justification fgor pedantic people to scream "NO, there is NONE"
Just ignore them
If you ignore pedantic people, you're unlikely to learn anything.
Who are you to decide which issues are irrelevant?
If you want to tell us that some compiler supports most of C99, that's
fine. If you tell us, without qualification, that it supports C99,
and in fact it fails to support some C99 features (such as designated
initializers, structure initializers with the dot notation, and macros
with variable argument lists), then your statement is at best
incomplete, and at worst simply untrue.
As I said elsethread, a conforming C90 compiler is *nearly* a
conforming C99 compiler; C90 is most of C99. If I were to claim that
"gcc -ansi -pedantic" is a C99 compiler (with an unstated assumption
that the features that are in C99 but not in C90 are not
"significant"), I doubt that you would take my statement seriously.
You can write portable conforming C99 code today, simply by avoiding
any C99-specific features. (Such code is also portable conforming C90
code.)
You're a compiler implementer. You *should* be pedantic.
--
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.
"Harald van Dijk" <tr*****@gmail.comwrites:
Keith Thompson wrote:
>I don't believe that Intel's compiler fully supports C99. If you can
demonstrate that it does, please do so.
Having just tested it, I can demonstrate that it does not.
$ cat test.c
int main (void)
{
printf ("Hello, world!\n");
}
$ icc --version
icc (ICC) 9.1 20060816
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
$ icc -strict-ansi -c99 -Wall test.c -o test
$ ./test
Hello, world!
(C99 requires a diagnostic for syntax errors, and undeclared
identifiers are a syntax error.)
It's a constraint violation, not a syntax error, but both constraint
violations and syntax errors require diagnostics.
Perhaps there's some other set of command-line options that cause icc
to be (more nearly) conforming?
--
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 wrote:
"Harald van Dijk" <tr*****@gmail.comwrites:
Keith Thompson wrote:
I don't believe that Intel's compiler fully supports C99. If you can
demonstrate that it does, please do so.
Having just tested it, I can demonstrate that it does not.
$ cat test.c
int main (void)
{
printf ("Hello, world!\n");
}
$ icc --version
icc (ICC) 9.1 20060816
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
$ icc -strict-ansi -c99 -Wall test.c -o test
$ ./test
Hello, world!
(C99 requires a diagnostic for syntax errors, and undeclared
identifiers are a syntax error.)
It's a constraint violation, not a syntax error, but both constraint
violations and syntax errors require diagnostics.
6.5.1p2:
An identifier is a primary expression, provided it has been declared
as designating an
object (in which case it is an lvalue) or a function (in which case it
is a function
designator).77)
77) Thus, an undeclared identifier is a violation of the syntax.
Perhaps there's some other set of command-line options that cause icc
to be (more nearly) conforming?
According to the documentation, -strict-ansi -c99 is enough to get icc
to (attempt to) conform to C99. Does the standard require that an
implementation accurately describe how to invoke it in a conforming
mode?
On Wed, 27 Sep 2006 21:33:15 +0200, jacob navia
<ja***@jacob.remcomp.frwrote:
>If you ignore pedantic people, there are MANY more.
If you ignore pedantic people, than you will have only an approximate
knowledge of real things. "Almost 100% conformant" is simpy NOT
conformant, so the answer "NO, there is NONE" is really correct if all
the compilers available are ALMOST 100% conformant.
"Harald van Dijk" <tr*****@gmail.comwrites:
Keith Thompson wrote:
>"Harald van Dijk" <tr*****@gmail.comwrites:
[...]
(C99 requires a diagnostic for syntax errors, and undeclared
identifiers are a syntax error.)
It's a constraint violation, not a syntax error, but both constraint
violations and syntax errors require diagnostics.
6.5.1p2:
An identifier is a primary expression, provided it has been declared
as designating an object (in which case it is an lvalue) or a
function (in which case it is a function designator).77)
77) Thus, an undeclared identifier is a violation of the syntax.
Interesting. I'll have to take a closer look at that. (My copy of
the standard isn't available at the moment.)
I certainly think of using an undeclared identifier as a semantic
error rather than a syntax error, but sometimes the standard foolishly
disagrees with me. 8-)}
>Perhaps there's some other set of command-line options that cause icc
to be (more nearly) conforming?
According to the documentation, -strict-ansi -c99 is enough to get icc
to (attempt to) conform to C99. Does the standard require that an
implementation accurately describe how to invoke it in a conforming
mode?
Interesting question.
--
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.
jacob navia wrote:
If you ignore pedantic people
When were you appointed as the person who gets to draw the line between
what's "pedantic" and what's just plain wrong?
jacob navia wrote:
It is business talk.
If you write
This is 100% conforming you are liable if there is the
slightest bug. If you write "some" conformance, you are
not.
Oh really? You think the FSF is afraid of being sued?
Keith Thompson <ks***@mib.orgwrites:
"Harald van Dijk" <tr*****@gmail.comwrites:
>Keith Thompson wrote:
>>"Harald van Dijk" <tr*****@gmail.comwrites:
[...]
>(C99 requires a diagnostic for syntax errors, and undeclared
identifiers are a syntax error.)
It's a constraint violation, not a syntax error, but both constraint
violations and syntax errors require diagnostics.
6.5.1p2:
An identifier is a primary expression, provided it has been declared
as designating an object (in which case it is an lvalue) or a
function (in which case it is a function designator).77)
77) Thus, an undeclared identifier is a violation of the syntax.
Interesting. I'll have to take a closer look at that. (My copy of
the standard isn't available at the moment.)
I certainly think of using an undeclared identifier as a semantic
error rather than a syntax error, but sometimes the standard foolishly
disagrees with me. 8-)}
[...]
Yes, the standard agrees with your. (I didn't doubt your quotation, I
just wanted to look at the context.) But I would still question the
way the standard says this.
With a bit more context:
6.5.1 Primary expressions
Syntax
1 primary-expression:
identifier
constant
string-literal
( expression )
Semantics
2 An identifier is a primary expression, provided it has been
declared as designating an object (in which case it is an lvalue)
or a function (in which case it is a function designator).77)
[...]
77) Thus, an undeclared identifier is a violation of the syntax.
So the "Syntax" section clearly says that an identifier is a primary
expression, but the "Semantics" section says this applies only if it's
been declared as designating an object or a function. It's odd that
the "Syntax" section doesn't completely describe the syntax; it seems
to me it would have been more sensible to say that an identifier is
always a primary expression, and the use of an undeclared identifier
is a semantic error, not a syntax error. (Sometimes an aspect of the
syntax can be more easily stated in English rather than in BNF, but it
doesn't seem necessary in this case.)
But as I said, sometimes the standard foolishly disagrees with me. 8-)}
--
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 wrote:
jmcgill said:
>>GCC is working towards C99 conformance, but it's not complete.
When was the last change to GCC that increased its C99 conformance?
(I'm guessing four or five years ago, but I'll be glad to be proved wrong.
It would be nice to know they're at least still having a crack at it...)
As far as I can tell, the last improvement occurred with the release of
GCC 4.0 on April 20, 2005. This release implemented the "integer
promotion rules". Not a big change.
It seems that the GCC team doesn't view enhancing C99 conformance a high
priority, though they are incrementally improving it. The docs imply
they intend to complete it someday. (The -std=gnu99 option is documented
as, "ISO C99 plus GNU extensions. When ISO C99 is fully implemented in
GCC, this will become the default. The name `gnu9x' is deprecated.")
--
Eric Schmidt
--
Posted via a free Usenet account from http://www.teranews.com
On Wed, 27 Sep 2006 20:20:18 GMT, Frederick Gotham
<fg*******@SPAM.comwrote in comp.lang.c:
=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= posted:
int Func(void) {}
int main(void) { Func(); return 0; }
This is a strictly conforming program in C99.
Over on comp.lang.c++, we were discussing the idea of a non-void-returning
function not having a return statement. One of the participants claimed that
it was UB in C99 because of the following:
(section 6.8.6.4/1,
a constraint on the return statement): "A return statement without an
expression shall appear only in a function whose return type is void."
A constraint violation merely requires the compiler to issue a
diagnostic. And, of course, as you point out below, your original
sample code did not violate the constraint.
Furthermore, the program has well-defined behavior in all versions of
ISO/ANSI C, because the caller does not attempt to use the returned
value of the function (6.9.1 para 12).
However, I read that to mean that the following is broken:
int Func(void) { return; }
Not strictly conforming, in the sense that it requires a diagnostic.
rather than the following being broken:
int Func(void) {}
Not even a constraint violation.
Even with the constraint violation, as long as the compiler issues a
diagnostic, there is nothing preventing it from producing an
executable. No undefined behavior is involved in either case unless
the caller attempts to use the return value.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
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
sunny wrote:
Hi All
What is C99 Standard is all about. is it portable, i mean i saw
-std=C99 option in GCC
but there is no such thing in VC++.?
which one is better ANSI C / C99?
can i know the major difference between C99 & ANSI C standards?
I think ANSI C is much enough. If you want to use C99, why not use C++?
------
Yubo
Keith Thompson wrote:
With a bit more context:
6.5.1 Primary expressions
Syntax
1 primary-expression:
identifier
constant
string-literal
( expression )
Semantics
2 An identifier is a primary expression, provided it has been
declared as designating an object (in which case it is an lvalue)
or a function (in which case it is a function designator).77)
[...]
77) Thus, an undeclared identifier is a violation of the syntax.
So the "Syntax" section clearly says that an identifier is a primary
expression, but the "Semantics" section says this applies only if it's
been declared as designating an object or a function. It's odd that
the "Syntax" section doesn't completely describe the syntax; it seems
to me it would have been more sensible to say that an identifier is
always a primary expression, and the use of an undeclared identifier
is a semantic error, not a syntax error.
Is (a) (b) an explicit conversion of b to type a, or a call to function
a (or *a), passing b as the only parameter? In C, the syntax alone
can't resolve this.
Yubo wrote:
I think ANSI C is much enough. If you want to use C99, why not use C++?
C99 is C, and when it is superseded, that will be C.
I remember early in my C career, that others were sticking to
K&R-style function prototypes, and I remember thinking this was annoying
(mainly because I just couldn't believe people refused to use ANSI C
prototypes).
I *still* deal with code where people use K&R style function prototypes
(I realize they aren't prototypes).
Back then, I always assumed they knew better, that there must be target
systems that need that "lowest common denominator" or whatever. But now
I realize there wasn't a compiler anywhere in the whole shop that wasn't
ANSI-C conforming. Eventually I recognized that I'd been dealing with
programmers who learned one way to do things, and just didn't think
about it. You know the type: Programming is their day job, and it
stays at the door when they leave the office.
I don't want to be one of those people with regard to the C99 standard,
or future developments.
As for C++, I've got to say I've been dabbling in Objective-C lately,
and I must say I find it exciting, bundled with the MacOSX framework
classes and XCode of course. I've never found C++ "exciting"...
Keith Thompson wrote:
With a bit more context:
6.5.1 Primary expressions
Syntax
1 primary-expression:
identifier
constant
string-literal
( expression )
Semantics
2 An identifier is a primary expression, provided it has been
declared as designating an object (in which case it is an lvalue)
or a function (in which case it is a function designator).77)
[...]
77) Thus, an undeclared identifier is a violation of the syntax.
So the "Syntax" section clearly says that an identifier is a primary
expression, but the "Semantics" section says this applies only if it's
been declared as designating an object or a function. It's odd that
the "Syntax" section doesn't completely describe the syntax; it seems
to me it would have been more sensible to say that an identifier is
always a primary expression, and the use of an undeclared identifier
is a semantic error, not a syntax error.
(I could've sworn I replied to this already, but my message just isn't
showing up...)
The syntax alone isn't and can't be enough to tell whether (a) (b) is a
cast or a function call.
"Harald van Dijk" <tr*****@gmail.comwrites:
Keith Thompson wrote:
>With a bit more context:
6.5.1 Primary expressions
Syntax
1 primary-expression:
identifier
constant
string-literal
( expression )
Semantics
2 An identifier is a primary expression, provided it has been
declared as designating an object (in which case it is an lvalue)
or a function (in which case it is a function designator).77)
[...]
77) Thus, an undeclared identifier is a violation of the syntax.
So the "Syntax" section clearly says that an identifier is a primary
expression, but the "Semantics" section says this applies only if it's
been declared as designating an object or a function. It's odd that
the "Syntax" section doesn't completely describe the syntax; it seems
to me it would have been more sensible to say that an identifier is
always a primary expression, and the use of an undeclared identifier
is a semantic error, not a syntax error.
Is (a) (b) an explicit conversion of b to type a, or a call to function
a (or *a), passing b as the only parameter? In C, the syntax alone
can't resolve this.
Yes, that's a good point.
Note that this is an issue only if a is (or might be) a typedef.
Typedefs really mess up C's syntax; they were the biggest problem I
had a few years ago when I was working on a C parser. A typedef name
in effect becomes a context-specific keyword, because the built-in
type names (int, float, etc.) are keywords, so the parser has to use
information from the symbol table.
(If, as in some other languages, type names could be merely
identifiers, and the grammar were adjusted for consistency, we
wouldn't have this problem, but typedefs were added after much of the
language had already stabilized.)
I still would have said that an undeclared identifier is a semantic
error, and is assumed not to be a typedef, but that's just me.
--
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.
jmcgill wrote:
sunny wrote:
>Hi All
What is C99 Standard is all about.
It takes a long time for standards to become widely adopted in the field.
>is it portable
It is portable among systems implementing the standard, if you can find
any.
>i mean i saw
-std=C99 option in GCC
GCC is working towards C99 conformance, but it's not complete.
>but there is no such thing in VC++.?
And Microsoft reports having no plans to implement this standard.
>which one is better ANSI C / C99?
Which one is better, ketchup or mustard?
>can i know the major difference between C99 & ANSI C standards?
What qualifies as "major" is a matter of opinion. Some important
differences
. Identifiers have increased significant length
. "//" style comments are allowed
. Variable arguments in macros
. Inline functions
. Restricted pointers (can be "restricted" from pointing to the same
object.)
. a _Bool type
. Vars can be declared anywhere in a block
. Functions no longer return 'int' by default
. Last data member of a struct can be an array of unspecified size
. Complex number type
. Repeated type qualifier is folded into a single qualifier. (Though a
special case is made for "long long" which provides a 64 bit integer type.
The "restricted pointer" (two pointers cannot reference the same memory
address) allows compiler implementors to perform certain optimizations:
http://www.accu.informika.ru/accu/ev...lic/c_news.htm
Complex (and a distinct "Imaginary") type will have applications in
signal processing and number-theoretic algorithms. With Complex numbers
being a language feature, implementations may be able to optimize
arithmetic operations, so that for instance, library calls will not be
necessary for arithmetic.
I don't think supply the "Complex" type is a good choice. This type
can't be mapped to some hardware structure directly. Maybe it will lead
to more obfuscation opportunities and make the language more complex
than before.
Some of these standards are already de-facto standards in many systems,
like "//" comments, long identifiers, inline functions, 64-bit "long
long", incomplete array in a struct.
Some are no doubt going to lead to more obfuscation opportunities.
Vararg macros? I can see very useful application for that, but I can
see more potential for abuse.
Read "The Rationale for the C99 Standard"
http://std.dkuug.dk/JTC1/SC22/WG14/w...onaleV5.10.pdf
--
Yubo Xie
Yubo Xie <xi*****@gmail.comwrites:
[...]
I don't think supply the "Complex" type is a good choice. This type
can't be mapped to some hardware structure directly. Maybe it will
lead to more obfuscation opportunities and make the language more
complex than before.
I don't understand your objection. The "_Complex" or "complex" types
(not "Complex", and not a single type) were introduced because they're
mathematically meaningful. Whether they map to some hardware
structure is not particularly significant. And they should have no
effect on code that doesn't need complex numbers.
--
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 wrote, On 27.09.2006 21:35:
Harald van D?k said:
>Richard Heathfield wrote:
<snip>
>>So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.
You mean one, right? IBM's? It was mentioned in this thread,
Oops, must have missed that. Okay, one, then.
And presumably the C99 source code is portable between the IBM compiler
and... er... the IBM compiler. Excellent. Nice one, ISO.
Man, you're annoying when it comes to C99. ;-)
What about the vendors on this list? http://www.peren.com/pages/cvsa_isocvpl.htm
Boa This thread has been closed and replies have been disabled. Please start a new discussion. |
