Does your C compiler support "//"? (was Re: using structures)

[Ross Ridge]

The problem isn't with Microsoft or any other vendor. The problem is
with C99, it's a failed standard.

That's true

I read this a few times now. Why is the C99 standard failed?

Because almost no one has adopted it. C99 maybe a standard in name,
but it's not functioning as one.

Ross Ridge

 

[Stewart Brodie]

Because almost no one has adopted it. C99 maybe a standard in name,
but it's not functioning as one.

By "no-one" do you mean vendors or programmers? Obviously you need a
handful of vendors to support it first so that tools are available. But
then, I think it is responsibility of the programmers to adopt the new
standard *IF* the new features are going to make their jobs easier and they
can build the software for the targets they need. It is the latter point
that is the stumbling block so far, IMHO.

I have source code that requires a C99 compiler. I wanted to use this code
again in a different project. I had to rewrite it when we wanted to compile
it with gcc (2.96 in -ansi -pedantic mode - forced by requirements of the
project). I'd have been better off writing it in "old C".

From what I recall of the early 1990s, tools such as ansi2knr
(http://www.cs.wisc.edu/~ghost/index.html) could be used to compile C89 code
in K&R C compilers. On some platforms, I'm still using cfront to compile
old C++ code in a C89 compiler, although it's pretty much useless for
anything written later than the mid 1990s.

Are there any tools available which can convert C99 source code into code
that can be compiled by a compiler compliant to the pre-C99 standard? If
there are, and they are freely available, in source form (so they can be
build for "any platform"), then I believe take-up would be much faster as it
removes the obstacle of compatibility.

 

[Francis Glassborow]

I'm sure this is all very meaningful to those of your who are actually
on the committee. Possibly, you shouldn't be discussing it in public;

You are almost certainly correct.

I'm not sure what the relevant rules say. However, since you have
decided to refer to this dispute in a public forum, could you please
explain in sufficient detail for the benefit of those of us who
weren't there?

The document id the TR on Embedded C.

Specifically, what was being voted on? What is the "document in
question"? What is the "other document"? What are the actual arguments
for the two points of view that are in conflict? So far I've heard
only procedural complaints; I'd like to know what is the actual
substance of the dispute.

And the other document id the C99 version of the C Standard.

The substance of the dispute is that where a country elects to vote 'no'
on a formal vote they are supposed to list what changes to the document
being voted on would change their vote to yes. I was the only person on
the BSI C Panel (equivalent to ANSI J11) who voted for the UK to vote
yes for the TR, I was also the only person who has regularly attended
WG14 meetings in the last three years.

I think that is all that should be said and this matter should now be
dealt with within WG14 and the BSI.

 

[Douglas A. Gwyn]

Because almost no one has adopted it. C99 maybe a standard in name,
but it's not functioning as one.

That's nonsense. Each new release of each major compiler
has been successively closer to C99 conformance, with
some claiming to have reached full conformance. Just
because they didn't manage to incorporate, test,
document, package, etc. all the new features the same day
the standard was released doesn't mean that the standard
"failed".

Also note that with the exception of a few new features
(e.g. VLAs, generic math functions, <stdint.h>) C99 is
essentially the same as C89. Some of the new features
were easy to add and appeared sooner than the deeper
changes.

In fact I've been using some of the new C99 library
facilities (<stdbool.h>, <stdint.h> for example) quite
successfully even on older platforms. Having a standard
for such things is indeed useful.

 

[Douglas A. Gwyn]

The substance of the dispute is that where a country elects to vote 'no'
on a formal vote they are supposed to list what changes to the document
being voted on would change their vote to yes.

Yes, that's right. An alternative would be to state that
no conceivable changes could possibly justify a standard
in this area. But that would be an unreasonable position.

 

[Larry__Weiss]

Yes, that's right. An alternative would be to state that
no conceivable changes could possibly justify a standard
in this area. But that would be an unreasonable position.

Seems like "the camel's nose" type of scenario.

Is it never the case that a document is so ill-advised that it needs to
be rejected totally?

 

[Richard Heathfield]

Seems like "the camel's nose" type of scenario.

Is it never the case that a document is so ill-advised that it needs to
be rejected totally?

It's trivial, from a "list of changes" perspective, to change a very
ill-advised document into a - um - well-advised document. (The reverse,
alas, is also true.)

Without wishing to cast aspersions on your question, I can turn it into an
answer with just two mods:

s/Is it/It is/
s/\?/\./

You can do similar tricks to make any document say anything, of course.

 

[Al Grant]

Why should Microsoft support C99?

You can't have it both ways. First you yourself used terms like "mud-
slinging" and "wilful [sic] non-conformance".

No he/she didn't, that was me.

 

[Douglas A. Gwyn]

Is it never the case that a document is so ill-advised that it needs to
be rejected totally?

It's not the case in this instance.

 

[Michel Bardiaux]

Richard Kettlewell wrote:
[snip]

$ cat t.c
// does it work?
$ cc -c t.c
"t.c", line 1: error(1166): expected a declaration
// does it work?
^

1 error detected in the compilation of "t.c".

I see no option to make the IRIX compiler accept // comments.

[snip]
Strange. On mine (IRIX64 usrco 6.5 01100601 IP27), same t.c and same cc
command, no diagnostic. Besides, the man page mentions the switch
-Xcpluscomm

Ah! But we have the N32 as default. So:

cc -n32 -c t.c
(no diagnostic)
cc -o32 -c t.c
cfe: Error: t.c, line 1: Syntax Error
// does it work?
^
cc -o32 -Xcpluscomm -c t.c
(no diagnostic)

 

[Larry__Weiss]

It's trivial, from a "list of changes" perspective, to change a very
ill-advised document into a - um - well-advised document. (The reverse,
alas, is also true.)

Without wishing to cast aspersions on your question, I can turn it into an
answer with just two mods:

s/Is it/It is/
s/\?/\./

You can do similar tricks to make any document say anything, of course.

OK, then let me also do some rewording to:

Has it ever been the case that a document was so ill-advised that
it was rejected totally?

If "no" then I'm feeling stronger about the "camel's nose" analogy.
That is, that getting a document to the point of taking a vote (the nose is
now under the tent flap) assures the adoption of the document in perhaps
ammended form (the camel is in the tent).

The "camel" in this case would be the outcome that the scope or "size" of
C is increased.

IMO, C should exist as K&R wrote:
C is not a very "high level language", nor a "big" one, and
is not specialized to any particular area of application.

 

[Phil Tregoning]

Richard Kettlewell wrote:
[snip]

$ cat t.c
// does it work?

This code is not a very good test.

$ cc -c t.c
"t.c", line 1: error(1166): expected a declaration
// does it work?
^

1 error detected in the compilation of "t.c".

I see no option to make the IRIX compiler accept // comments.

[snip]
Strange. On mine (IRIX64 usrco 6.5 01100601 IP27), same t.c and same cc
command, no diagnostic. Besides, the man page mentions the switch
-Xcpluscomm

Both C89/C90 and C99 require at least one "external-declaration"
in a translation unit (see K&R2 A13 or the standard). This TU:

// does it work?

requires a diagnostic, even in C99.

Phil T

 

[Samuel Barber]

That's nonsense. Each new release of each major compiler
has been successively closer to C99 conformance, with
some claiming to have reached full conformance.

Perhaps you could list the "major compilers".

Sam

 

[Stewart Brodie]

Stewart Brodie <[email protected]> wrote in message

Why didn't you use C++?

The target platform could not support C++. Specifically, the GNU exception
mechanism will not work in our run-time environment, let alone the problem
of the C++ run-time support library libstdc++ being far too large - around
300KB for MIPS Linux).

 

[James Kuyper]

Which one is that? (as per 'versions c_dev)

It's not true of our current 7.3 system, but according to their web
site it is true of 7.4:

http://www.silicongraphics.com/developers/devtools/languages/c.html

 

[Ross Ridge]

I read this a few times now. Why is the C99 standard failed?

Because almost no one has adopted it. C99 maybe a standard in name,
but it's not functioning as one.

That's nonsense. Each new release of each major compiler
has been successively closer to C99 conformance...

No, they're just implementing the features of C99 their customers
actually want. The goal isn't full C99 conformance.

... with some claiming to have reached full conformance.

What's the other one then?

Just because they didn't manage to incorporate, test, document, package,
etc. all the new features the same day the standard was released doesn't
mean that the standard "failed".

The standard wasn't released yesterday. And well, almost all vendors
were committing to and even claiming C89 conformance before that standard
was even released. It's a much different situation now. It's been now
four years, with very little adoption, very little interest. It's time
now to face the reality that the standard has failed.

In fact I've been using some of the new C99 library
facilities (<stdbool.h>, <stdint.h> for example) quite
successfully even on older platforms. Having a standard
for such things is indeed useful.

Indeed. And if C99 had been the kind of standard where you can pick and
choose what you want implment, then I'd say C99 was a reasonable success.
But, it's not that kind of standard, and so its success is measured by
implementations that claim to fully comply, not those that just implement
bits and peices of the standard.

Ross Ridge

 

[Francis Glassborow]

The standard wasn't released yesterday. And well, almost all vendors
were committing to and even claiming C89 conformance before that standard
was even released. It's a much different situation now. It's been now
four years, with very little adoption, very little interest. It's time
now to face the reality that the standard has failed.

The world of 2003 is very different from 1989/90. To start with there
are multiple languages wanting the attention of implementors (many of
the tasks being done by C in the 80's are now done by C++ and Java, C#
etc. absorb many of the new requirements. There is also very little if
any spare money around with the result that implementors have to focus
on whatever pays the bills.

There is also the issue that first time standardisation is much easier
than subsequent releases (look at the problems that Fortran had with its
later standards, though they were not actually failures they did take a
long time to get adopted.)

In order to determine if something has failed you have to specify what
it was intended to achieve, it is not enough to just declare that
slowness with adoption demonstrates failure.

 

[Greg Comeau]

Richard Kettlewell wrote:
[snip]

$ cat t.c
// does it work?

This code is not a very good test.

$ cc -c t.c
"t.c", line 1: error(1166): expected a declaration
// does it work?
^

1 error detected in the compilation of "t.c".

I see no option to make the IRIX compiler accept // comments.

[snip]
Strange. On mine (IRIX64 usrco 6.5 01100601 IP27), same t.c and same cc
command, no diagnostic. Besides, the man page mentions the switch
-Xcpluscomm

Both C89/C90 and C99 require at least one "external-declaration"
in a translation unit (see K&R2 A13 or the standard). This TU:

// does it work?

requires a diagnostic, even in C99.

Perhaps he did not put it into strict C99 mode.

Anyway, for instance, here is the Comeau C99 error:

E:\tmp>como --A --c99 t.c
Comeau C/C++ 4.3.3 (Aug 21 2003 13:51:58) for _MS_WINDOWS_x86
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C99

At end of source: error: a translation unit must contain at least one
declaration

 

[Douglas A. Gwyn]

That is, that getting a document to the point of taking a vote (the nose is
now under the tent flap) assures the adoption of the document in perhaps
ammended form (the camel is in the tent).

That's not really true, witness some of the items in the first
C TR, but when you consider that the reason for production of
a TR is that there was strong enough demand to justify the
work project, it is not surprising that the product gets used.
The C standards committee is not academia; we don't invent
stuff just because it seems like a cute idea.

 

[Douglas A. Gwyn]

Which one is that? (as per 'versions c_dev)

According to
http://www.sgi.com/developers/devtools/languages/index.html

Languages
C
Now Supports ISO/IEC c99 Standard As of the 7.4 release of the MIPSpro C
Compiler, the C compiler supports the c99 standard when invoked with the
-c99 flag or when the c99 command is used. [more]