Storgae durations

[Keith Thompson]

(e-mail address removed) writes: [...]

Have they actually said, "we don't have a C99
implementation"? If so, could you point me to the site where it's
stated?

It's implied by <http://gcc.gnu.org/c99status.html>,

The site marks the features and failures of C99 in GCC. Where does say
that they don't have a C99 implementation? The most relevant part I
found regarding this subject is

"This page describes the C99 support in mainline GCC, not in any
particular release."

unless you insist
on referring to implementation that doesn't fully conform to the C99
standard as a "C99 implementation".

That's precisely what I've been saying.

Then we have a disagreement over terminology.

I suggest that using the term "C99 implementation" to refer to an
implementation that doesn't fully conform to C99 is more likely to
cause confusion than to convey useful information.

And my statement that a C90 compiler implements most of C99 was quite
serious. Either a pure C90 compiler or the current gcc (which
implements C90 and most, but not all, of the C99 features that aren't
in C90) implements *most* of C99. It's a difference of degree.
Either allows you to program in a subset of C99; in the former case,
that subset is the intersection of C90 and C99, and in the latter it's
the set of features that the gcc folks have gotten around to
implementing.

The qualitative difference is that the former subset is far more
portable. Code written in the intersection of C90 and C99 is usable
either with a fully conforming C90 compiler (of which there are many)
or with a fully conforming C99 compiler (of which there are only a
few). Code written in the C99 subset that gcc currently supports is
usable either with a fully conforming C99 compiler (of which see the
previous sentence) or with gcc (of which there's gcc). A non-gcc
more-than-C90-but-less-than-C99 compiler is unlikely to support
exactly the same set of features that gcc supports.

If gcc's mostly-C99 mode is good enough for your purposes, that's
great. It's just not good enough for everyone's purposes.

 

[santosh]

A pure C90 implementation with no extensions also supports most of
C99.


It's implied by <http://gcc.gnu.org/c99status.html>, unless you insist
on referring to implementation that doesn't fully conform to the C99
standard as a "C99 implementation".

That's precisely their bone of contention. Richard's definition
of "conforming implementation", and which the Standard also states, is
one which implements (modulo bugs) *all* the mandatory semantics and
features of the Standard. This is a demanding but reasonable
definition. C90 *was* implemented fully by the majority of C compilers
and one would've have expected the same for the current C Standard.
That it didn't happen is disappointing.

As a response to C99 relative failure Richard prefers to continue to
code in C90 (or to be precise, in the common subset of C90 and C99),
while many other programmers do use commonly implemented features of
C99. Some may even exclusively use C99, though this is probably rare.
Such code won't be as portable as strict C90 code, but if it meets the
requirements of the programmer and client, then it's fine.

Whether a "non-conforming" C implementation or a "nearly conforming"
implementation like GCC (to C99 of course) is usable is rather
subjective. Some programmers are naturally "tool oriented" and prefer
to fully use powerful tools and don't care much about maximal
portability or standard's conformance, while some others are
naturally "standards oriented" and prefer to (as strictly as possible)
follow ratified and de facto standards (and note that a sufficiently
popular tool can itself become a "de facto" standard, so there is a
thin line between what one might consider standard and what not.)

The extremes of both positions are almost impossible and the position
one must adopt on this line for a particular project depends on it's
requirements, and our prior experience (aka common sense.)

This is an interesting issue, but unfortunately the present participants
are rather entrenched in their opposing positions and the discussion
has descended into claims for "proof" and word wrangling.

 

[Richard]

G> jacob navia said:

No, I mean ISO C. That certainly includes C99. It also includes C90.



No, in late 2007 this was debated at length, and the group decided
*against* extending topicality, despite the opinions of those who,
like

No. You and a few sycophants discussed it. Since most people have you
and your clique killfiled because of your constant rudeness and ego
mania then most didn't even see this "discussion".

 

[Richard]

Keith Thompson said:


Well, there /is/ a distinction. If I recall correctly (which I might not),
it was Greg Comeau who started out by advertising that Comeau C "conforms
to C99", but later adapted the claim to "supports C99" because he'd found
a sticking-point that he hadn't (at that point in time) been able to fix.

So to support your ridiculous attempts at twisting things you quote
someone most people have never heard of who mislead people?

Amazing. Even for you.

 

[Richard]

(e-mail address removed) said:


It is not in dispute that C90 *was* the Standard against which people
programmed (because this was certainly the case before C99 existed). It is
you who claim that things have changed - that most people now use C99. The
burden of proof is therefore on you. (Saying "it's so" does not constitute
proof.)

It is as valid to ask you to prove your claims that C90 is the dominant force.

 

[santosh]

Richard Heathfield wrote:

In the case in point, whether C99 is the "current" standard depends on
what we mean by "current". Implementors have ignored C99 in droves,
and most current implementations conform to C90 but not to C99. There
is therefore little point in holding up C99 as the "current" standard
because it's... well, I won't say it's unimplemented because that's
clearly not the case - but it's not so widely implemented that those
who care about portability can yet reasonably assume that all those
who will be compiling their software have a C99 implementation
available. [ ... ]

BTW, is it technically possible for an ISO standard to be withdrawn and
replaced with the previous version?

Coming back to Standard C, perhaps WG14 could have taken out the least
implemented parts of C99 (such as complex.h, tgmath.h, stdint.h, VLA,
fenv.h etc.) and put them in an annexes for optional features, much
like annexe F of the current Standard. This wouldn't change things on
the ground, but it would mean that a lot more implementations can apply
to themselves the label "conforming", which increases the "feel good"
factor, which seems to be often more important than worthier
considerations.

 

[Richard]

Barry Schwarz said:


Thank you, Barry.

Was this said with gritted teeth? Since it makes you look like a
complete and utter dickhead.

"Support C99" does not mean "conforms to C99" indeed. Where do you get
off talking such nonsense and continually playing ridiculous word games
in your attempts to belittle Jacob?

 

[santosh]

So to support your ridiculous attempts at twisting things you quote
someone most people have never heard of who mislead people?

Greg Comeau has been a semi-regular participant here for at least as
long as I have been participating and very probably for much longer
(Google Groups will show this). He has been on the Committees for C and
C++ and his implementation (Comeau C/C++) is high quality one, by all
the looks of it.

You have here accused him of misleading people when you should have
applauded the fact that he had the intellectual honesty to revoke the
conformance claim of his implementation upon noticing a difficult bug.
How many industry "big guns" do do this?

Despite your contempt for RH, you should try not to impulsively lash out
at everyone else too.

 

[santosh]

G> jacob navia said:

No. You and a few sycophants discussed it. Since most people have you
and your clique killfiled because of your constant rudeness and ego
mania then most didn't even see this "discussion".

Funnily enough, I suspect that most people have actually killfiled you
and your two "fellows in arms", Twink and McCormack.

Personally, I don't believe in (or use) killfiles.

 

[s0suk3]

(e-mail address removed) said:



Yes, it's certainly very difficult to prove something that isn't true.

You don't know whether it's true or not.

Fine. By the same token, we've yet got to see whether it's true that Elvis
is alive but was carried off by aliens. Nevertheless, until proof to the
contrary emerges, I am content to accept the most likely scenario - i.e.
that the King is dead. Likewise, until proof to the contrary emerges, I am
content to accept the most likely scenario - i.e. that most C programmers
are not using C99-conforming implementations.

Well of course you can have (inaccurate) assumptions about the
subject, and they have a certain percentage of probability of being
true. Most programmers probably do so as well. But we've yet got to
see a prove.

Since the first C99-conforming implementation appeared some considerable
time (a lot more than a minute) after the C99 Standard was adopted, I am
content to accept the most likely scenario - i.e. that it did not become
the most widely used standard from the minute it was available.

Yes, well, that was a rather hypothetical scenario (hence the word
"diminutive"), and only to illustrate the point.

Nevertheless, in the absence of - at the very least - some kind of credible
supporting evidence, I accept the most likely scenario, i.e. that C99 is
not as widely used as C90 by a very, very long way indeed.





Thank you for the link. I have read it with some interest.


To you, perhaps the page is convincing. To me, it raises a couple of
interesting question marks. Firstly, and I don't know whether you noticed
this, that page cites C89 as "currently the de facto standard for C
applications", a claim with which I agree. Secondly, I find the statement
"C99 conformance and feature support" ambiguous. Does it mean that the
compiler conforms to C99, or does it mean that the compiler offers
"support for C99 conformance and features"? If the former, then it is
indeed a conforming C99 implementation (assuming we can trust Intel to
tell the truth about that, which seems likely). If the latter, then it may
not be. I don't feel particularly strongly about it either way. In your
defence, I should point out that Intel uses the same wording to describe
its C89 (effectively C90) support, which suggests that the C99 conformance
may indeed be there. (Good!)

Thanks!

The point initially was whether it was free or not, though, which it
is.

[...] everybody and his dog has a C90-conforming
implementation, and of course there are plenty of free C90
implementations.
So is the case for C99.
Perhaps you'd be so kind as to provide some URLs.

Whenever you're so kind as to provide URLs that prove that everybody
and his dog has a C90-conforming implementation.

Do you really, really, really think they haven't? C90 is probably the most
widely implemented language standard ever!

I do think they do. Likewise for C99.

Here is a short and far from exhaustive list of C90 conforming
implementations:

Borland C (several different compilers)
C/370
CodeWarrior
Comeau C
Digital Mars C
gcc (various ports exist for a number of platforms)
Hitech C (TWELVE different compilers for various platforms)
Intel C
lcc
LE370
Microsoft C
Norcroft C
Sun C (a variety of compilers)
Watcom C
VisualAge C
XL C (for a variety of platforms)

These compilers provide support for PCs running MS-DOS, Windows (various
flavours), Linux, Unix (various flavours); for MacOS; for a number of
mainframe operating systems; for a whole bunch of DSPs; for PDAs such as
the Palm; and many many more.





Let's get this straight, once and for all. Do you use a conforming C99
implementation? If so, which one? (If your answer is "gcc", then no, you
don't use a conforming C99 implementation.)

No.

And I never claimed I did.

I said I used a C99 implementation.

You're weaselling. Either you use a conforming C99 implementation or you
don't. Decide.

No.

And I never claimed I did.

My point is that your statement, "False" (quoted above), is unsupportable.

I said "False," and nothing else, because I didn't feel the need to
support the statement. You said

"Given that most people starting to write new apps don't actually have
a C99 implementation,"

Which is, let's admit it, gibberish. Do I really need to say anything
else but "False"?

Cut to the chase. Are you using a conforming C99 implementation? (gcc isn't
one.)

No.

And I never claimed I did.

Let me give you an example of a proof, using this (rather badly-drawn)
diagram:

A B C
+---*-------+
| |
| * D
| |
| |
E * |
| |
+-------*---+
F G H

Step 1: draw your own version of the diagram, such that ACFH and BDEG are
squares, with each of the smaller square's corners touching the larger
square.

Step 2: let the distances AB, CD, EF, and GH be 'a', and let the distances
BC, DH, AE, and FG be 'b', and let the distances BE, EG, GD, and DB be
'c'.

Step 3: the area of the large square can be expressed as follows:

Area = (a + b) * (a + b)

Step 4: the area of the large square can be expressed in another way, by
summing the areas of the four triangles ABE, EFG, GHD, BCD and the area of
the square BDGE, i.e. as:

Area = 4 * (a * b) / 2 + c * c

Step 5: two things that are equal to the same thing are equal to each
other:

(a + b) * (a + b) = 4 * (a * b) / 2 + c * c

a(a + b) + b(a + b) = 2ab + c*c

a*a + ab + ab + b*b = 2ab + c*c

a*a + 2ab + b*b = 2ab + c*c

Subtracting 2ab from both sides:

a*a + b*b = c*c, QED.

That's a proof. Given the normal mathematical axioms, this proof is
inescapable. Its truth is not a matter of opinion. It *necessarily*
follows from the axioms. Even if you don't believe the axioms, the proof
still follows from them, because the proof is a process that proceeds from
the axioms. So you might not accept, for example, that multiplication is
commutative, in which case you might deny that the proof describes reality
- but the proof is nevertheless correct, even if it doesn't describe
reality. It is *not* a matter of opinion. Anyone who doesn't find it
convincing needs to go back to school (or is nitpicking the axioms and
wrongly considers this to be a way of knocking the proof).

It's as simple as this: Not everything is as exact and concise as
mathematics. There are times where there can't be a logical,
calculated, and correctly measured solution to a problem. This kinds
of problems are therefore, to a much larger extent, subject to each
person's beliefs and interpretations of the problem. There are even
times were there's no single answer to a problem. This discussion is a
clear example.

It is in the nature of a proof that the steps from axioms (and
already-established theorems) to the conclusion are clear and inescapable
to a sufficiently educated person. Your "proof" was merely a collection of
ifs:

++++++++++++++ context restored +++++++++++++++++

(you)>> >> > I don't know exactly which platforms are supported by C99

+++++++++++++++++++++++++++++++++++++++++++++++++

Your "proof" changed the focus from C99's portability - an objective
concept - to your standards of portability - a subjective concept.

It wasn't subjective in the way I described it. What I said was, in
other words, that I knew of enough platforms that support C99 in order
to mark it as portable, even though it might be more portable than I'm
actually aware of. This is only subjective in the sense that what is
portable to /me/ isn't portable to /everybody/, but that'd be the case
too even if I did know of all the platforms that support C99.

And as this shows, there's no completely objective way to discuss any
implementation's or standard's portability, and no way to form a
mathematically calculated proof.

It also
begged the question (i.e. it assumed the thing you were trying to prove -
that C99 programs are widely portable).

There's no way to objectively and universally prove that, and it isn't
what I was trying to prove. What I was trying to prove (only on that
paragraph) is that I /was/ in position of making arguments about C99's
portability, unlike you claimed.

Furthermore, it made improper use
of an implicit assumption that the mere availability of a C99
implementation for a platform indicates that a significantly large
proportion of C developers using that platform have obtained a copy of
that implementation.

How so? Why do you think it made that assumption?

Limiting the code to a subset of the language won't reduce
portability.

That is precisely why I limit my code to the subset of C99 that is also
legal C90.

[...] Because I
cannot rely on my users having C99, I can't use C99 (except the bits of
it that are also C90, of course).

Hilarious. If they don't tell you anything about their system, how can
you know they even have a C90 implementation?

Because everybody and his dog has a C90 implementation.

So would be the case for C99.

But I don't want to beg the question myself, so let's look at it another
way. If by some strange chance there is a C programmer out there who
doesn't have a C90 implementation, that programmer is not one of my users
(because he or she is not using my code, because they can't, because they
don't have a C90 implementation). Therefore, all my users have C90
implementations.

Well if they don't object to you the first time you send them code
they can't compile, it's only logical to assume they do have a C90
implementation. So the bottom line is that it would be equally
acceptable to send them any code: C99, C++, Java! And if they
don't object, then it means it's OK.

That makes the whole point null.

Not at all.

Not according to GNU. Forgive me, but I think [GNU] have a better idea
of whether their product conforms than you do.

Like I've said, I only say it's a C99 implementation because you can
compile C99 programs in it and because it supports most of C99 (i.e.,
it's common sense). Have they actually said, "we don't have a C99
implementation"?

I don't know whether they've ever used those precise words, but...

If so, could you point me to the site where it's stated?

... http://gcc.gnu.org/c99status.html makes it very clear.

Like I already told Keith, they don't mention that there.

Sebastian

 

[Joachim Schmitz]

santosh wrote:

Personally, I don't believe in (or use) killfiles.

Same here. I apply a virtual killfile on a case by case basis.
Seems usefull on part-time trolls. And trolls in this group, that don't
troll in others

Bye, Jojo

 

[Richard]

Funnily enough, I suspect that most people have actually killfiled you
and your two "fellows in arms", Twink and McCormack.

I suspect most of the clique have indeed. Because they dont like having
their contributions dissected and laughed at.

I was recently re-reading the "mythical man month" and sniggered to
myself how much better these projects would have been with cbfalconer,
heathfield etc all who dont need debuggers and rarely debug stages.

You see I, and I suspect kenny and twink, really do have real industry
experience on big projects. So we *know* how much bullshit certain
posters here produce. We dont say these claims are "impossible" we just
say that most of these claims have no place in a public group where some
people might think these claims are the norm. Claims of fixing 50,000
line programs (someone elses) from a glance at the printout are such
claims that cause me to chuckle and shake my head. Can one do it? Of
course one MIGHT do it. Of course some people HAVE done it. Would any
analyst programmer worth his salt recommend that as the way to do it? Of
course not. That ridiculous quote from Kernighan bandied around by one
of the more self important regs makes we want to give him (the poster) a
poke in the eye :-;

Personally, I don't believe in (or use) killfiles.

Me neither. As a general rule. Although I finally had to add
Bwian (Default Loser), Bill, and "Chuck" since their trolling and net
nannying bordered on the ridiculous. heathfield was in there (his ego
makes me cringe) but auto scoring popped him out again recently. But
having seen hos continued lies and agenda against Jacob he might just
have to go back in. Which is a shame - since if you can stomach his
preening arrogance and read between the lines of his convoluted "look
how clever I am" English grammar he certainly knows a lot about an old
C standard (although how applicable that is in the modern day is
debatable).

 

[s0suk3]

(e-mail address removed) said:







See above.


That's *precisely* what it is. Eye-witness evidence is an account by an
eye-witness (i.e. someone who has seen something relevant) of that which
he (or she) has seen.

It's possible that you have observed such evidence, but even if that's
the case, you haven't presented it in this discussion (and that would
be of course hard to accomplish given the present media of
communication!). So, since the evidence is not presented, it's the
same as if there were no evidence :-(

Look, I can see that you're twisting and turning the very best you can, and
you're actually doing it pretty well - but you are massively hampered by
your complete absence of a case,

By the same token, we both are.

so you're having to feign ignorance of
ordinary words and concepts. At least, I hope you're feigning. I wouldn't
want for anyone to be that ignorant.

It's not ignorance. It does may seem as if we're not making much use
of common sense anymore, but that's because we've carried the
discussion up to the point where mere common sense fails to
sufficiently support the cases.

I've already explained that I'm speaking of what I have *observed*, not
what I have imagined. But since we're on the subject of imagination, where
is this great cloud of C99 programmers that you seem to envisage as
covering the programming world?

People working on projects, friends programmers, etc, but I can't
prove this, so is there any point in mentioning it?

Not only my opinion, but the opinion of several other people in this
thread, and they are very knowledgeable people too.

One major problem you have in this discussion is that, by drawing a
distinction between "C99 implementation" and "conforming C99
implementation", you must either define what *you* mean by "C99
implementation" (and as far as I'm aware, you haven't yet done this) or
risk being misunderstood by almost every participant in this thread.

I don't think that would happen, since I would expect most people to
use the terms as I do.

Do you consider Visual C to be a C99 implementation (by your definition of
the term)? If so, why? If not, why not?

How about Borland C? How about gcc?

I haven't used Visual C or Borland C, so I can't comment on them. I do
consider gcc to be a C99 implementation, but we've discussed that more
than enough in this thread, right?

Is the implementation of *one* C99 feature (that isn't also a C90 feature)
sufficient to make an implementation "C99"?

I think most people in general would not consider that.

So where are they all, then, these C99 installations and programmers?

All around us, but I'm afraid I can't show you reality from where I'm
sitting.

Then you've got no business saying "False", have you?

Well, "False" doesn't really prove anything and doesn't provide much
useful content; it just states that it's my total opinion that the
claim is false, which is sometimes all one can do in discussions like
this.

Sebastian

 

[James Kuyper]

It's possible that you have observed such evidence, but even if that's
the case, you haven't presented it in this discussion (and that would
be of course hard to accomplish given the present media of
communication!).

He has told you what he witnessed. That is precisely what an eye-witness
does in court when presenting eye-witness evidence.

I don't think that would happen, since I would expect most people to
use the terms as I do.

But your expectations don't seem to be a particularly close match to the
reality that I observe. I found dozens of examples of many different
people using the term in a manner inconsistent with the idea that it
means "nearly conforming", and only you and jacob navia using it in ways
that clearly require that meaning. That means that the only person you
can be sure won't misunderstand what you meant to say is jacob.

 

[Joachim Schmitz]

Jack Klein, 2000-08-08:
"gcc might well be the most compliant C99 implementation available
today, and might very well be the first with acceptable compliance,"

http://groups.google.com/group/comp.lang.c/msg/739b38f3bc2f9acc

I think you snipped too much, actually he wrote:
"gcc might well be the most compliant C99 implementation available
today, and might very well be the first with acceptable compliance,
however one decides to define that. But the last I heard there were
quite a few parts of C99 undone. "


And this was more than 8 years ago, but unfortunaly that last sentence is
still true.



Bye, Jojo

 

[s0suk3]

(e-mail address removed) said:





It is *true* that I have.

....which we've yet got to see.

Yes, I have - several times now.

When?


You really need to get a clue.

I don't need to get a clue about the way you see the world.

No.

Ummm.. Yes.

Well, one of us surely isn't.

Well, as we've learned, we don't share a common sense.

Common sense suggests that we believe our own experience, but tempering it
with that of others whom we trust. My experience tells me that there are a
very great many people using C90 implementations, and nobody is using C99
implementations - but I'm prepared to accept that my experience is not
universal

Good! I don't usually snip, but in this case I made an exception and
snipped the rest of the paragraph, since that last sentence is all
that is relevant.

Yes, of course there is! It doesn't *prove* your case, but it is evidence
in support of your case (assuming you're not lying, and I don't see any
reason why anyone should accuse you of that). But it is only evidence in
support of your case if these people really were/are using conforming C99
implementations. If you just mean "C90 with extensions", you're really
proving my point rather than your own.

A non-conforming C99 implementation is not necessarily C90 with
extensions. GCC, for example, has a C90 implementation, a C99
implementation, and two more implementations: a C90 implementation
with extensions, and a C99 implementation with extensions. (I'm not
sure if this are the only ones.)

That expectation has been questioned heavily in this thread, so surely you
must realise that *even if you were right in general* (which I don't
accept), you're wrong in this thread, because most people who've expressed
an opinion in this thread disagree with you - and those are the very
people with whom you're trying to communicate.

But not the only ones, though.

Why?

(Answering below...)

Maybe we're getting to the heart of it. Why is gcc a C99 implementation?
What makes it a C99 implementation, given that it doesn't conform to C99?

Several obvious and meaningful facts:

- It supports most of C99 with minor failures
- People use it as a C99 implementation
- Some/most people consider it to be a C99 implementation
- Perhaps most importantly, it is *usable* as a C99 implementation

Two features? Four? Where is the line?

There's no universal such line, since it depends on people's opinions.
That's why I mentioned the words "most," and "in general."

If you make assertions of falsehood without being able to support them, the
time will quickly come when people pay less and less attention to such
assertions.

It isn't intended for people to pay much attention to them; it's
intended to state that it's my opinion that the claim is false,
without making much of a big deal out of it.

Sebastian

 

[lawrence.jones]

I think I can tell the difference between a C90 installation and a C99
installation. For one thing, any Visual C installation conforms (when
suitably kicked) to C90, but none of them conform to C99, no matter how
hard you kick them. Same applies to Borland and gcc. Same applies to
Norcroft. Same applies to C/370 and LE370.

I believe that C/370 does conform to C99 now (with suitable kicking).

 

[jameskuyper]

...which we've yet got to see.


When?

The issue in question is the following words Richard Heathfield wrote

You can claim that most people use C99 even when the observable evidence is
heavily weighted in the other direction, but nobody has to believe you.

Richard Heathfield has presented the following eye-witness accounts as
evidence against the claim that most people use C99:

Date: Mon, 18 Aug 2008 14:02:53 +0000

... I've been using C since 1989, and by far the overwhelming
majority of C programmers I've known personally and "met" on the Net use
implementations that conform to C90 but not to C99. ....
...My
favourite example is a Web browser product for set-top boxes that was
already well-established when I joined the project, and which comprised
about half a million lines of code, of which 99% (495,000 lines or so) was
written in ISO C - and yes, it was C90, not C99, although C99 had been the
de jure standard for at least a couple of years by then. Every time they
needed to add support for a new platform - which seemed to happen two or
three times a year - they only needed to rewrite around 5000 lines of
code, which took about a month each time. I don't think it's possible to
write a decent modern Web browser in ISO C - but I *do* think it's
possible to write 99% of a decent modern Web browser in ISO C, because
I've seen it done.

I included that last item because it's very definitely an eye-witness
account, even though it's only marginally relevant to the claim being
challenged.

Date: Tue, 19 Aug 2008 02:23:41 +0000

... I've cut a lot of C code for a lot of
companies over the years, on a fair number of platforms - but when I've
been writing C on the PC, I have invariably used either Microsoft C, gcc,
or Borland C. Every company for which I ever wrote PC-based code (and a
few that I turned down, and a few that turned me down) used one of those
three implementations. I never came across a company that used any other
implementation for PC-based code. And none of those three implementations
is C99-conforming.

Date: Wed, 20 Aug 2008 09:28:01 +0000, and reposted on
Date: Wed, 20 Aug 2008 19:27:33 +0000:

I've already explained that I have *observed* - not imagined, but
*observed* - a great many C90 installations (i.e. a particular
implementation of C90 installed on a particular machine), on a wide
variety of machines, being used by a wide variety of C programmers.

I have never once seen anyone use a C99 implementation. I have never seen a
C99 installation. Not once, not ever.

These are all presentations about what he himself has witnessed/seen
with his own eyes/observed. That makes them eye-witness evidence. Eye-
witness evidence can be a pack of lies, it can be biased (it usually
is), it can be irrelevant, or insufficiently detailed or
insufficiently complete to support a particular conclusion. Like all
evidence, you have to assess it's quality, internal and external
consistency, and it's source, in order to decide how much credence to
give it. But none of those issues make it cease to be eye-witness
evidence.

 

[lawrence.jones]

Thanks, Larry - I guess one can't walk over the same river twice...

I don't know why not -- I've had the same ax for 20 years, though I did
have to replace the handle four times and the head twice.

 

[Flash Gordon]

Since you make no attempt to refute this point a reasonable person can
assume you accept it. So we can accept the position that there are NOT
many C99 implementations.

But you know, there's a bigger number of programmers in the world than
"more than two people in this thread." So I don't see how that's an
evidence.

By this argument *you* have not produced any evidence and you just
making wild unsupported claims. However, back in the real word, it is
evidence, as is the research other people have done with Google on this
issue and presented in this thread.

Since you have been presented with evidence that you are wrong you
should either accept it or find and present some counter-evidence.

[...] Either you use a conforming C99 implementation or you
don't. Decide.
No.
And I never claimed I did.
Fine. We have now established that you do not use a conforming C99
implementation.
So far so good...
Good. Since an implementation that does not conform to C99
is not a C99 implementation, we have also established that you do not use
a C99 implementation. Good. Finally.
...but not so good. False.
So what do you mean by a C99 compiler? Remember that an old pre-ANSI
standard compiler can correctly compile C99 code provided you stick to
the portions of C99 that it supports.
Sure, but that isn't usually the case for compilers that claim to
support C99, either conforming or not.

So far in this thread we have had example which claimed "support for"
which, on further investigation turned out to be fully conforming. We
have gcc which *explicitly* states in both the web pages and the info
page (in the section which describes the C99 flag) that it is *not*
complete. I know of one other compiler where the author claims C99
support but has not yet completed it. So the evidence currently is that
usually they only claim C99 support (without mentioning it being ^^^^^^^^^^^^^^^^^^^^^^^^^^^
incomplete) if they are conforming implementations.

^^^^^^^^^^

Wrong. Read

http://gcc.gnu.org/c99status.html

"This page describes the C99 support in mainline GCC, not in any
particular release."

So they *do* claim support without claiming conformance.

They mention it is incomplete. Well, actually they clearly state it is
broken (their term not mine). I've also presented evidence that GNU do
not consider it to be suitable for use as a C99 implementation (i.e.
that they will not change the default until it is).

[...] You said
"Given that most people starting to write new apps don't actually have
a C99 implementation,"
Which is, let's admit it, gibberish.
No, it's simply true.
False.
Hmm. Microsoft Visual Studio is probably the most used C compiler on
Windows and it does not even *attempt* to come close to C99.
But it isn't the only C compiler on Windows.

No, just the most common by a very long way. So it is almost certainly
the compiler most commonly used when developing new C application on
Windows. So it not conforming to C99 is very strong evidence that you
are wrong.

First you say "No [it isn't the only C compiler on Windows], just the
most common by a very long way." And then you say that I'm wrong. Your
above paragraph contradicts itself.

I'll be clearer as you could not understand what I wrote. MS VCC is by
far the most used Windows C compiler, so whether it is the *only*
compiler is irrelevant to what most new C development is done in. MS VCC
has NO support for C99. Therefore most new C development on Windows is
NOT done in C99. This is a strong piece of evidence (but not the only
evidence) that most new C development is not done in C99.

There is no contradiction in my original paragraph.

Like I discussed with Richard, we've yet got to see what they say
about it, since until now we haven't seen them state those words
either implicitly or explicitly.

The most you can do is rule gcc out of this discussion completely in
that case. I.e. don't consider it to support either your claim or the
claim of everyone else currently participating in this thread. After
all, you have been presented with evidence for GNU not considering it to
be C99 implementation (i.e. the one place which mentions C99 support
states it is broken).

Not everybody is like you.

True. I have heard of both K&R and C99. Most C developers will have
heard of K&R but *not* C99.

*Eye witness evidence*
The only C developers I have come across who have heard of C99 *before*
I have mentioned it to them are people on this group.

Since the GNU folks haven't said they don't have a C99 implementation,
and since not everybody is like you, then that is no such thing as a
strong evidence.

Well, it certainly is not evidence for your position. So shall we just
go on the compilers where there is no dispute then?

Are you certain that the majority of C programming takes place on
embedded systems? Could you prove it?

Where is your evidence that embedded systems development is a special
case? I know (because I used to work there) that BAE Systems uses C for
embedded systems works (it was still growing in popularity when I left),
but NONE of the non-embedded work was in C (C++, Delphi, VB etc but NO C).

You mentioned the words "C90 + extensions." If I missed the point,
it's because you failed to state your point.

Well, for a start by your definition of what a C99 implementation is a
"C90 + extensions" implementation is a C90 extension. So by your
arguments if people are working in C90+extensions (a lot of SW uses
extensions for at least some of the work) then they are using C90.

In any case, if the development is in C90+extensions then it is NOT in C99.

But you didn't talk about not enabling conformance; you talked about
C90 + extensions.

I talked about the mode most people have their compiles in, as evidenced
by the reports on this group whenever the question arises. If the
compiler supports C99 but the user is using it in a mode other than
either C99 or C99+extensions then they are definitely NOT using C99 so
whether it supports C99 is completely irrelevant to what language they
are using. Otherwise you can say that all gcc users are programming in
Fortran.

So why do you claim that most new C development is in C90 +
extensions?

No, I claimed that is the mode the compiler is in. If it is in
C90+extensions mode then the development is NOT being done in C99.

Can you prove that? Until you do, it's safe to assume that most people
*do* attempt to use anything approaching C99.

By that argument it is safe to assume that most people are using C90.
However, I have also presented evidence and arguments that justify my
position where as you just keep restating yours and denying (without
giving and sensible reason) the evidence.

I strongly do not believe that.

Several arguments have already been presented for why it would be the
case. The only argument put forward for your position has already has
already been refuted.

Where do I draw the border between a C89 and a C99 implementation?
Simple: a C89 implementation supports C89; a C99 implementation
supports C99.

OK, since I've only seen one implementation that makes no form of claim
to supporting C89 that means all implementations bar one are C89
implementations. Oh, and explicitly broken support (GNU claim their C99
support is broken) just means that it is a broken compiler (in that

How so?

Well, you don't refute it so you obviously accept it.

Furthermore, [your argument] made improper use
of an implicit assumption that the mere availability of a C99
implementation for a platform indicates that a significantly large
proportion of C developers using that platform have obtained a copy of
that implementation.
How so? Why do you think it made that assumption?
I don't know why your argument made that assumption.
Then that makes your whole point null.
You have miss-interpreted each other.
Richard meant (I think) that he does not know why you chose to make that
assumption. He does understand what about your argument assumes that.
But I don't see how my argument made that assumption.

You start off trying to prove that most new C development is in C99

I'm not trying to prove that, as I know it's impossible to prove it
(just as it is impossible to prove the opposite). I simply point it
out.

Well, several of us have "just pointed out" that you are wrong. The
difference is that we have actually presented evidence.

Neither does it mean that they aren't.

As it accept my point you should also accept the conclusion that your
claim (if true) that most C developers have a C99 is NOT evidence that
most C developers use a C99 implementations. Oops, you have just lost
your most claimed argument for your position.

It isn't very likely.

Simple percentages disagree. There are more non-C99 compilers than C99
compilers (a point you have accepted) so the law of averages supports my
position.

Anyway, what does that have to do with
management specifying which compiler to use, even if there is C99
availability?

I stated that in the text you quote above.

By the same token, it is also a possible reason for not using a C90
implementation.

No. It is only a reason for not using a C90 implementation if they use
the ONE compiler which only "supports C99" (which does not provide
compete support) or they use an ancient K&R compiler which does not
support C99 or C90. So the simple law of averages says it is more likely
to mean they do not use C99 than that they do not use C90.

Alternatively, I'm going to toss a coin 50 times. Each time it lands on
its edge I will give you $1000 and each time it doesn't you give me
$100. You should accept since both outcomes are possible and you will
get 10 times more money that you have to give me!

That doesn't have anything to do with not being aware of free
implementations.

It has everything to do with whether they are using C99 which is the
point of the discussion.

Have I ever denied that a C99 compiler approaching conformance has
been under active development?

I was just pointing out that you were talking complete rubbish. It was
an aside and nothing to do with the main point of this thread.

I don't think this is true. Anyway, can you prove it? Until you do,
it's safe to assume that you're wrong.

You not being able to prove me wrong does not make it safe to assume I
am wrong. In fact, since my position is presented with evidence and
argument where-as yours is supported by wild assertions it is safer to
assume you are wrong.

How so?

Because you failed to find any problems with the rebuttal.

No, it has no relevance. Richard started by saying that not everyone
can afford a C99 implementation, and that OF THOSE WHO DO, (1) not
everyone likes them, (2) of those who do, not everyone can make the
decission of buying them, (3) and of those who do, not everyone wants
to spend money on them. Then I replied by saying that those three
points are equally applicable for an implementation of any standard.

Incorrect because there is only one compiler that has been identified
that has any kind of support for C99 (although it is incomplete) but no
support for C90. Therefore if they *have* a compiler (any compiler) it
*definitely* meets one of the following (unless they have that one
specific Windows compiler):

1) It supports K&R and does *not* support C99
2) It supports C90

I can think of only 4 compilers that do not support C90, three of those
do not support C99 and are used almost exclusively for one specific
purpose (recompiling Unix kernel modules to change parameters) and the
last is for Windows and is used on Windows far less than either gcc or
MS VCC.

Then you replied by saying that it's difficult to find compilers that
don't conform to C90, which is completely unrelated to what was
previously being discussed.

It is entirely related to your unfounded claims that anything true of
C90 (e.g. the chances of a randomly selected compiler supporting it) are
equally true of C99.

I.e. it refutes most of the attempts you just made at rebutting my points.

When have I said that Richard's work is for embedded systems?

You have accepted that embedded compilers are more likely to be C90 than
C99 and yet you claim that Richards customers are most likely to be able
to accept C99. Those to claims amount to a claim that you believe that
Richard's work is not used in embedded systems since they would not be
likely to accept C99 (by your own admission) if it was.

I also have no idea if Richard's SW is used in embedded systems, but I
am not the one claiming to know that his customers would find C99
acceptable.

Have [GNU] actually said, "we don't have a C99
implementation"?
I don't know whether they've ever used those precise words, but...
If so, could you point me to the site where it's stated?
...http://gcc.gnu.org/c99status.htmlmakesitvery clear.
Like I already told Keith, they don't mention that there.
Yes, they do, by listing the ways in which their implementation does not
conform to C99.
That doesn't imply the words "we don't have a C99 implementation"
either explicitly or implicitly.
Well, there info page states as the reason for not making gnu99 the
default mode (instead of gnu89) that it is not fully implemented. Since
the extensions GNU provide to C99 are *also* extensions they provide to
C90, it is obviously the implementation of the base C99 language they
consider to be too far from compete for it to be the default mode. That,
to me, *does* imply that they do not consider gcc to have a C99
implementation yet, just something they are working on getting there.
To me, it implies that they consider GCC to have a C90 implementation,
a C99 implementation, and a custom implementation of their own for
each of the two standards. But we've yet got to see what they say.

The GNU developers do not often post here. However you should be able to
see why some people (most people don't care) consider it to imply that
they do not have a C99 implementation.

It isn't about what some people consider; it's about what it implies
or not, and what you said does not imply that they do not have a C99
implementation.

There is enough of an implication for at least some people to read it
the way Richard and I have read it. Therefore that page does not prove
your point. In fact, we have more evidence for it refuting your point
than for it supporting your point.