C99 Versus ANSI.

[Eric Schmidt]

jmcgill said:


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

 

[Jack Klein]

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= posted:



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.

 

[Yubo]

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++?

 

[Guest]

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.

 

[jmcgill]

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

 

[Guest]

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.

 

[Keith Thompson]

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.

 

[Yubo Xie]

It takes a long time for standards to become widely adopted in the field.


It is portable among systems implementing the standard, if you can find
any.



GCC is working towards C99 conformance, but it's not complete.


And Microsoft reports having no plans to implement this standard.


Which one is better, ketchup or mustard?


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/events/public/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.

 

[Keith Thompson]

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.

 

[boa]

* Richard Heathfield wrote, On 27.09.2006 21:35:

Harald van D?k said:


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

 

[Skarmander]

jacob navia said:
[on C99]

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.

Although your other comments are well taken, this one misses the mark.
Portability is not quite a non-issue on Microsoft platforms (there's still
some 16-bit and 64-bit code to worry about, and those funky CE platforms),
but it's not far off. Those people who have to port non-Windows-specific
programs to Windows usually avoid Visual C++, and those people who use
Visual C++ usually don't care about porting or creating non-Windows-specific
programs.

In short, whether Microsoft implements C99 may matter to Windows
programmers, but to the general issue it matters only slightly. The fact
that C99 is poorly supported between platforms with more exchange of code is
more important.

S.

 

[Richard Heathfield]

boa said:

Man, you're annoying when it comes to C99. ;-)

I do my humble best.

What about the vendors on this list?
http://www.peren.com/pages/cvsa_isocvpl.htm

Interesting page - for those who can't be bothered to go look, it's a list
of vendors that have been awarded validation certs for C99 software. Here's
a brief summary:

Dinkumware's C99 library (no compiler, though) for Linux
Edison Design Group C99 compiler (no library) for Linux

(The two together make a conforming implementation.)

IBM XL C99 compiler (not clear whether a library is included) for Power PC

IBM Visual Age C99 compiler (library not clear) for Power PC

Lund C99 compiler (library not clear) for Linux/Power PC

Solaris: a couple of compilers, library status not clear, one for SPARCs and
the other for x86s running Solaris.


So the situation is improving. But I don't see any compilers there for
Win32, Win64, BSD, embedded systems, mainframes, or minicomputers. That's
quite a hole.

 

[Skarmander]

Oh really? You think the FSF is afraid of being sued?

No, but there's a quite different reason for that:

"This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."

Never mind C99 conformance, they're not even claiming gcc is good for
anything. They've pretty much got that base covered.

S.

 

[jmcgill]

"This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE."

Never mind C99 conformance, they're not even claiming gcc is good for
anything. They've pretty much got that base covered.

Show me a software vendor that sells anything to the public that does
not make an equivalent disclaimer in the license.

 

[Skarmander]

Show me a software vendor that sells anything to the public that does
not make an equivalent disclaimer in the license.

From the Windows XP EULA: "Microsoft warrants that the Software will
perform substantially in accordance with the accompanying materials for a
period of ninety (90) days from the date of receipt."

Of course, this doesn't mean Microsoft promises you an OS that will work
well, and the EULA also takes great pains to distance itself from any
possible damages that could arise as a result of the use of the software,
but that's another issue.

S.

 

[Richard Heathfield]

Skarmander said:

jacob navia said:
[on C99]

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.

Although your other comments are well taken, this one misses the mark.
Portability is not quite a non-issue on Microsoft platforms (there's still
some 16-bit and 64-bit code to worry about, and those funky CE platforms),
but it's not far off. Those people who have to port non-Windows-specific
programs to Windows usually avoid Visual C++, and those people who use
Visual C++ usually don't care about porting or creating
non-Windows-specific programs.

That is directly contrary to my own experience. Much of my career has been
spent writing code which was non-Windows[1]-specific but which nevertheless
had to be developed on Windows[1]. Typical scenario: the program is
intended to be run on a mainframe system but the mainframe people don't
want lots of hairy C programmers milling around their environment (and who
can blame them?); so they give you a Windows[1] box and Visual C[2] to get
the darn thing written and working *first*, and then they let you throw it
at the big iron for final testing.

One place I worked, though, they used Borland C 3.1 (despite the fact that
16-bit was ancient history by then). Weird. But a pleasant change.
(Curiously, I am fairly sure I got that particular contract purely because
I'd *heard* of "thunking". Blech!)

[1] Or, in earlier days, MS-DOS.
[2] Or, in earlier days, Microsoft C.

 

[Skarmander]

Skarmander said:

jacob navia said:
[on C99]
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.

Although your other comments are well taken, this one misses the mark.
Portability is not quite a non-issue on Microsoft platforms (there's still
some 16-bit and 64-bit code to worry about, and those funky CE platforms),
but it's not far off. Those people who have to port non-Windows-specific
programs to Windows usually avoid Visual C++, and those people who use
Visual C++ usually don't care about porting or creating
non-Windows-specific programs.

That is directly contrary to my own experience. Much of my career has been
spent writing code which was non-Windows[1]-specific but which nevertheless
had to be developed on Windows[1].

Back in the days when the only Microsoftese port of gcc was DJGPP, I take
it? You'd presumably be much better off using mingw these days.

Typical scenario: the program is intended to be run on a mainframe system
but the mainframe people don't want lots of hairy C programmers milling
around their environment (and who can blame them?); so they give you a
Windows[1] box and Visual C[2] to get the darn thing written and working
*first*, and then they let you throw it at the big iron for final
testing.

Ouch. In that case, I feel your pain. On the other hand, a good conforming
implementation (never mind C99) is even more to ask for in that case... and
I should hope that the scenario you sketch is either history, or no longer
forces VC(++) on the hapless programmers doing the cross-developing.

One place I worked, though, they used Borland C 3.1 (despite the fact that
16-bit was ancient history by then). Weird. But a pleasant change.

I had my share when I had to develop a Win 3.1/95 app with Visual C++ 1.42.
I fondly remember walking over to the tiny room that held nothing but the
printer and a spare computer, with a stack of Win 3.1 setup disks, to test
my latest creation...

Ah, the days of MFC and OWL. How I sorely don't miss them.

(Curiously, I am fairly sure I got that particular contract purely because
I'd *heard* of "thunking". Blech!)

[1] Or, in earlier days, MS-DOS.
[2] Or, in earlier days, Microsoft C.

S.

 

[Richard Heathfield]

jmcgill said:

Show me a software vendor that sells anything to the public that does
not make an equivalent disclaimer in the license.

"This device is provided without warranty of any kind as to reliability,
accuracy, existence or otherwise or fitness for any particular purpose
and Bioalchemic Products specifically does not warrant, guarantee,
imply or make any representations as to its merchantability for any
particular purpose and furthermore shall have no liability for or
responsibility to you or any other person, entity or deity with respect
to any loss or damage whatsoever caused by this device or object or by
any attempts to destroy it by hammering it against a wall or dropping it
into a deep well or any other means whatsoever and moreover asserts
that you indicate your acceptance of this agreement or any other
agreement that may he substituted at any time by coming within
five miles of the product or observing it through large telescopes or
by any other means because you are such an easily cowed moron
who will happily accept arrogant and unilateral conditions on a piece
of highly priced garbage that you would not dream of accepting on a
bag of dog biscuits and is used solely at your own risk." - Terry Pratchett

 

[boa]

* Richard Heathfield wrote, On 28.09.2006 21:57:

boa said:



I do my humble best.


Interesting page - for those who can't be bothered to go look, it's a list
of vendors that have been awarded validation certs for C99 software. Here's
a brief summary:

Dinkumware's C99 library (no compiler, though) for Linux
Edison Design Group C99 compiler (no library) for Linux

(The two together make a conforming implementation.)

IBM XL C99 compiler (not clear whether a library is included) for Power PC

IBM Visual Age C99 compiler (library not clear) for Power PC

Lund C99 compiler (library not clear) for Linux/Power PC

Solaris: a couple of compilers, library status not clear, one for SPARCs and
the other for x86s running Solaris.


So the situation is improving. But I don't see any compilers there for
Win32, Win64, BSD, embedded systems, mainframes, or minicomputers. That's
quite a hole.

What's a minicomputer?

I didn't spend much time on this, but have a few comments which I
believe are more or less correct:
- The EDG compiler *front end* is used by (lots of ?) vendors of
embedded systems, so C99 support for embedded systems may be better than
we think.

- The Dinkumware C99 library claims to be portable. I was unable to find
a list of supported platforms, but assume that it is portable to more
platforms than the next version of Linux...

- The SUN compilers now support Linux, AFACT.

And as we all know, C99 support in gcc isn't perfect, but probably good
enough for many tasks/people/projects/whatever.

I can't spend more time on this, so I'll switch back to read-only mode
now.;-)

Boa

 

[Jean-Marc Bourguet]

Solaris: a couple of compilers, library status not clear,

The library seems to be there. Do you want I check anything in detail?