Storgae durations

[s0suk3]

(e-mail address removed) said:

(e-mail address removed) said:

but even if that's
the case, you haven't presented [eye-witness evidence of
the overwhelming prevalence of C90 within the world of
C programming] in this discussion
Yes, I have - several times now.

When?

James Kuyper has already addressed this, so I'll move on.

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

Right. You need to get a clue about the way /you/ see it.

If I have a way to see it, that means I have a clue about the way I
see it.

Learn.

The fact that I don't do it doesn't mean I don't know how to do it. I
simply think it makes us lose context.

And while you're about it, learn how to do it without distorting the
meaning too much. The paragraph continued "and that at least /some/ people
are using C99 implementations. Nevertheless, they are sufficiently small
in number that they have never blipped my radar."


No, it isn't. The rest of the paragraph is highly relevant. If C99 were as
prevalent as you say, I'd have expected to see a few dozen installations
of it by now. And I haven't - which leads me to doubt your claims.

Your last sentence "but I'm prepared to accept that my experience is
not universal," was indeed very relevant, since it shows that you're
understanding that what /you/ see isn't as relevant to the rest of the
world as it is to you. The rest of the paragraph simply goes further
to comment on things about this rather irrelevant matter.

People working on projects, friends programmers, etc [are using C99],
but I can't prove this, so is there any point in mentioning it?
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.

Agreed. A non-conforming C99 implementation would be anything, anything at
all, that fails to translate program code according to the C99 Standard.

Well, it depends on what you mean by "non-conforming."

For example, it could be a copy of Visual Basic. That's a non-conforming
C99 implementation. So is ISPF/PDF. So is Lotus WordPro. So is KNode. So
is Apple Writer. So is Space Invaders. So is the coffee-cup on my desk.
"Non-conforming implementation" is not a particularly useful phrase.

Its usefulness, as with the usefulness of any phrase, depends on the
context.

<snip>





With whom else are you trying to communicate, then, in this thread, if not
the people who are reading it and contributing to it?

In *this* thread, it's obviously them.

I agree, but so did Turbo C, ten years before the C99 Standard was
published. So do you consider Turbo C a C99 implementation?

Would you say that it had "minor failures"? I think most people
wouldn't think so.

People use flat-head screwdrivers to turn cross-head screws. That doesn't
mean that cross-head screws are flat-head screws.

Of course, cross-head screws are not flat-head screws. What I'm saying
is not that GCC isn't a C99 implementation and that people use it as a
C99 implementation. What I'm saying is that, because of GCC being a
C99 implementation, people use it as a C99 implementation.

Most people have never heard of gcc. If you mean most C programmers, well,
most C programmers don't even know what main returns. I don't consider
their opinion particularly relevant.

Nevertheless, the masses are the masses, and they hold some power in
terms of expression.

Not if it doesn't conform to C99, for reasons which I have explained many
times.

Well, whether it is usable to you in particular is another matter.

That isn't good enough where, for example, business contracts are
concerned. If Company A contracts to supply software to Company B that
conforms to ISO/IEC 9899:1999, and Company B sues Company A because the
supplied software doesn't compile - or compiles with the wrong semantics -
on gcc, Company A can easily win the case if it can demonstrate that it is
gcc's failure to conform to the Standard that causes the failure to
compile or the incorrect semantics. The judge will not be impressed by
Company A's claim that "in our opinion gcc conforms to C99".

If I understood correctly, Company A was contracted to supply software
to Company B that conforms to C99, and that's exactly what they did.
What compiler Company B uses is another matter completely, so Company
B would have no case.

Whether gcc conforms to C99 is not a matter of opinion. It is a matter of
fact - and the fact is that, at present, it doesn't conform. GNU's C99
status page confirms this, by pointing out (and rightly so) all the places
where they know it doesn't conform.

Have I ever denied that?

Those are weasel words, and they don't get around the fact that gcc doesn't
conform to C99.

And they weren't meant to get around the fact that GCC doesn't conform
to C99. In fact, we weren't even talking about that. We were talking
about at what number of features people would consider an
implementation to be a C99 implementation. So, in this context, "most"
and "in general" are not weasel words; they're simply as accurate as
they can be.

Your strategy is working.

Seems like you're the one who should learn to snip without distorting
the meaning too much.

Sebastian

 

[Antoninus Twink]

Seems like you're the one who should learn to snip without distorting
the meaning too much.

Heathfield's entire modus operandi is to distort the words of those who
disagree with him to try to make them look stupid. He is a deceitful
weasel, and word games are all he knows.

 

[jameskuyper]

The fact that I don't do it doesn't mean I don't know how to do it. I
simply think it makes us lose context.

You should never snip needed context; but you keep a LOT of unneeded
context, and it makes your messages a pain to read.

....
True. The real point is that someone using "C90 with extensions" is
using a C90 compiler, which is relevant to the debate about whether or
not C90 compilers are overwhelmingly more common than C99 compilers.
In contrast, someone who's using something that does not conform to
C99 is not necessarily using a C90 compiler; they might be using lcc-
win32, or a Visual Basic compiler, or M$ Excel, or even a pencil
sharpener - none of which are relevant to that question.

Well, it depends on what you mean by "non-conforming."

Something that fails to meet one or more of the requirements that the
standard imposes on conforming implementations. Note, in particular,
that this includes failing to meet ANY of those requirements. Hence
the inclusion of the pencil sharpener.

Its usefulness, as with the usefulness of any phrase, depends on the
context.

In the context of a debate over whether or not compilers that fully
conform to the C90 standard are overwhelmingly more common than
compilers that fully conform to the C99 standard, using a term that
doesn't clearly identify the compiler as conforming to at least one of
those two standards is not very useful.

Would you say that it had "minor failures"? I think most people
wouldn't think so.

In 1989? How could it fail to have minor failures to conform to C99?
The process of writing the C99 standard hadn't even been started yet -
it would be an incredible feat of precognition to design Turbo C at
that time without any failures to conform to C99.

Richard's points is that all of those failures were minor - because
the differences between C90 and C99 are minor, relative to the
language as a whole.

Of course, cross-head screws are not flat-head screws. What I'm saying
is not that GCC isn't a C99 implementation and that people use it as a
C99 implementation.

He's not suggesting that you did.

... What I'm saying is that, because of GCC being a
C99 implementation, people use it as a C99 implementation.

Actually, you cited (8 lines up) the fact that people use it as a C99
implementation as a reason for considering it to be a C99
implementation. Your latest formulation reverses cause and effect.
Which order are you arguing for?

The correct statement is that a C99 implementation is always usable to
compile C99 code; something that is not a C99 implementation can
sometimes be used to compile some C99 code, but it cannot be used to
compile all C99 code.

If I understood correctly, Company A was contracted to supply software
to Company B that conforms to C99, and that's exactly what they did.
What compiler Company B uses is another matter completely, so Company
B would have no case.

But if Company B's opinion that gcc conforms to C99 were sufficient to
make gcc a C99 compiler, as you claim, then Company B should have had
a case..

 

[s0suk3]

Since you make no attempt to refute this point a reasonable person can
assume you accept it.

Yes, I accept that you would not consider a number smaller than (or
even close to) 10 to be "many." In fact, I accept that you consider
whatever you claim to consider. Whether those considerations are
accurate is another matter.

So we can accept the position that there are NOT
many C99 implementations.

Not the same thing.

By this argument *you* have not produced any evidence and you just
making wild unsupported claims.

Yes, I didn't produced any evidence. You have the evidence that "more
than two people in this thread" are also in agreement with you. But it
would take more than two people in this thread to consider any such
evidence to be relevant, so it is not much of an evidence.

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.

Google researches can't prove this.

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

No, I don't, since no such evidence has been presented.

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

Yes, but they do claim support, which is what I mentioned.

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 have not presented such evidence. The fact that it is not the
default doesn't mean they don't consider it to be suitable for use as
a C99 implementation. They also have a C89 implementation, and it also
isn't the default. Do they not consider GCC to be suitable as a C89
implementation? I wouldn't think so.

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

You forgot the words "in Windows" in that last sentence. And yes,
perhaps most new C development _in Windows_ is not done in C99, but
that wasn't what you objected to; it was to what I said about MSVC not
being the only C compiler on Windows.

There is no contradiction in my original paragraph.

You agreed that MSVC wasn't the only C compiler on Windows, and then
you claimed that I was wrong. That *is* self-contradiction.

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

No, I haven't been presented with such evidence.

(i.e. the one place which mentions C99 support
states it is broken).

It doesn't mention that C99 support is broken; it mentions which
features of C99 in GCC are broken. If you believe I'm wrong, please
provide a quote from the page where they explicitly state what you're
claiming.

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

The last sentence is wrong. But, what does that have to do with GCC
users having access to other compilers?

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

Really? In my case, the only C developers I have come across who have
heard of K&R before I have mentioned it to them are people on this
group. In fact, most people would hear about K&R and think about the
book (most likely the 2nd edition, actually), instead of the ancient
language.

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

So we shall.

Where is your evidence that embedded systems development is a special
case?

Actually, it's only common sense.

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



Well, for a start by your definition of what a C99 implementation is a
"C90 + extensions" implementation is a C90 extension.

I have never said that that's my definition of a C99 implementation.

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.

I've never made an argument saying that people are working in C90 +
extensions.

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

Agreed.



I talked about the mode most people have their compiles in, as evidenced
by the reports on this group whenever the question arises.

Could you point me to that evidence?

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.



No, I claimed that is the mode the compiler is in.

You did claim that most new C development is in C90 + extensions. Your
words were

"There, you now have a reasoned argument as to why most new C
development is in C90 + extensions and *not* in C99 - bits not
implemented or broken."

If it is in
C90+extensions mode then the development is NOT being done in C99.

Obviously.



By that argument it is safe to assume that most people are using C90.

Yes, safe, though I wouldn't bet on it...

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.

No, all you are doing is repeatedly claim to have some evidence which
(whether it's true or not) you are not presenting.

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.

I'm not sure which arguments you're talking about, but the ones in
this thread certainly haven't proved anything.

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)

No, they don't. Again, if you believe I'm wrong, please provide a
quote from the page where they explicitly state what you're claiming.

just means that it is a broken compiler (in that
mode) and so should be ruled out as being a <whatever> implementation.

Agreed.



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

The fact that I don't refute it doesn't mean I accept it. Though in
this particular case, it's true what you say about GCC's info pages
saying that the C99 standard is not fully supported. But that's
obvious--I don't need to further comment on 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.

No, you haven't. Again you're making wild claims about having some
evidence, and it's only reasonable to assume you don't have it since
you don't present it.

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.

It's not an evidence, as I pointed out, but it _is_ a strong clue.

Oops, you have just lost
your most claimed argument for your position.

No, I didn't.

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.

There are probably more non-C99 than there are C99 compilers, but the
reason I said it isn't very likely that C99 will not be available
because of management specifying which compiler to use is that it has
nothing to do with management specifying which compiler to use!

I stated that in the text you quote above.

You only made a comment about C99's availability. It had nothing to do
with management specifying which compiler to use.

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.

Not if they're not aware of any free C90 implementation, which was the
point in the first place anyway.

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!

Your analogy has nothing to do with being or not being aware of free
C90/C99 implementations.

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

Whether the compiler they're using provides C90 conformance but not
C99 conformance does not relate to being or not being aware of free
implementations.

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.

So you accused me of being wrong, and then make a completely unrelated
comment (by your own admission). That annuls both your claim about me
being wrong AND your claim about me talking rubbish. It also raises
some interesting questions as to what goes through your mind when you
make these replies.

You not being able to prove me wrong does not make it safe to assume I
am wrong.

No, you not being able to prove that *you*'re right makes it safe to
assume that you're 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.

Again you're claiming to have some kind of evidence, which you have
not presented. You only made some claims about the reasons people
would use C99, with NO supporting facts or evidence.

Because you failed to find any problems with the rebuttal.

You made no rebuttal; you simply talked about your C development
career.

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.

The three points were, again: of the people who can afford a C99
implementation, not everyone likes them; of those who do, not everyone
can make the decision of buying them; and of those who do, not
everyone wants to spend money one them. Then I say that those points
are equally applicable to an implementation of any standard, and you
refute to it by saying that there is only one compiler that supports
C99 but not C90. I don't see how you can link these things together.

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

<snip>

What if they can't afford them? What if they don't like them? What if
they can't make the decision of buying them? What if they don't want
to spend money on them? (In case you don't realize, these are the
points 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.

From that point of view, it is related, but it fails to explain why
the points made about C99 aren't equally applicable for an
implementation of any standard.

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

It doesn't, since hardly relates to what was being discussed, and
doesn't give any arguments against it.

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.

Yes, in general, considering my limited knowledge about their
requirements. But I never claimed that Richard's work is for embedded
systems.

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.

So you're assuming that I implicitly claimed that Richard's work is
not for embedded systems because (a) I make the assumption that they
would most likely be able to accept C99 code, and (b) because I
accepted that embedded systems would be a place where C90 would be
more advantageous. No, you misinterpreted my words; I never made that
claim, neither implicitly nor explicitly. You'd be better off not
assuming implicit claims that I have not explicitly stated.

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.

Neither did I claim to *know*; I claimed to *think* that, most
*likely*, and considering my limited knowledge about their
requirements, they 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.htmlmakesitveryclear.
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.

You have no evidence since you're only making an inaccurate assumption
about an implicit implication on their website. I, on the other hand,
am only pointing out what they have *explicitly* stated. Therefore, my
point is stronger.

Sebastian

 

[s0suk3]

(e-mail address removed) said:



Would that it were so.

<snip>





You indulged in selective quotation - either by accident or design. This is
the only time I've noticed you snipping at all, and you got it wrong. That
suggests either that you don't know how to snip or you're deliberately
doing it wrong.

Or perhaps it suggests that we have different opinions even when it
comes to snipping!

It does. So keep the important context, and lose the rest. If anyone needs
the long background, they can look it up in the archives. That's what
reference headers are for.






Reality is relevant to everyone. Had I claimed that "I've never seen a C99
installation, therefore they don't exist", I'd have been a laughing-stock,
and rightly so. But the fact that I have never seen one, in circumstances
where I would *expect* to see one if they were commonplace, is strong
evidence that they are not as common as you would have us believe.

It might be a strong evidence to you. But, unfortunately, not everyone
of us has the fortune of being able to see exactly what you see, so
the rest of us have the inconvenient need to either believe you're
wrong, or go find out ourselves, possibly ending up realizing that you
were wrong in the first place.

It's highly relevant that the number of reported observations of C99
installations in the field is significantly below what should be expected
if C99 installations were sufficiently common for your claim (that most
new C development is in C99) to be plausible.

Reported observations? If you're talking about /your/ reported
observations, remember that not everyone of us can see through your
mind. /My/ observations, on the other hand, do make my claim
plausible. But both your observations and my observations are unable
to illustrate anything useful in this case.

People working on projects, friends programmers, etc [are using
C99], but I can't prove this, so is there any point in mentioning
it?
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.
Agreed. A non-conforming C99 implementation would be anything, anything
at all, that fails to translate program code according to the C99
Standard.

Well, it depends on what you mean by "non-conforming."

I'll take this slowly, if I may - one step at a time.

By "non-conforming C99 implementation" I mean "not a conforming C99
implementation".

So far so good.

By "conforming C99 implementation", I mean the same thing the C99 Standard
does: "The two forms of conforming implementation are hosted and
freestanding. A conforming hosted implementation shall accept any strictly
conforming program. A conforming freestanding implementation shall accept
any strictly conforming program that does not use complex types and in
which the use of the features specified in the library clause (clause 7)
is confined to the contents of the standard headers <float.h>, <iso646.h>,
<limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A
conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program."

So anything that matches the description given by C99 of a conforming
implementation is necessarily a conforming C99 implementation.

So far so good.

Anything
that does not, is not.

Since the standard does not define the term "non-conforming C99
implementation," then the meaning of that term is subject to what
everyone of us thinks about it. For you, for example, KNode and some
other programs are C99 implementations. For me it isn't. And I'd bet
so would think most people.

So James was quite right to say that a pencil sharpener is a non-conforming
C99 implementation. It's a term too wide to be useful.

Well, for you it is.

It also depends on logic and common sense.

Exactly.



Then I suggest that in *this* thread, it may be useful to adjust your
expectations about terminology usage in line with reality.

That's exactly what I'm doing.

Yes. Turbo C implements most of C99. A lot more than that pencil sharpener,
for example.


What is your basis for thinking you know what most people think? (Sheesh.)

I don't think I *know* what most people think. I said I *thought* that
it wasn't what most people think. In other words, it's my assumption
that that's what most people think, not my claim.

Right. Using an X as a Y doesn't make it a Y.


No, you're saing that GCC /is/ a C99 implementation because (you claim)
people use it as one.

Yes, that's one of the points, but not the only one.

Proof:

I asked: "What makes it a C99 implementation, given that it doesn't conform
to C99?"
You answered with four points, one of which was that "People use it as a
C99 implementation".

Yes.


And now you're saying that people use it as a C99 implementation because it
is one - which completes the circular argument: it is one because people
use it as such, and people use it as such because it is one.



Are you seriously advancing in defence of your position the argument that a
group of lots of ignorant people are likely to be right because they can
shout louder than a group of relatively few educated people?

In general, I wouldn't think that. But in this particular case,
they're not likely to be right just because they can shout louder, but
because there's no general or official agreement on the subject and
therefore it is much subject to everyone's opinion. Plus, I don't
think it's only "a group of lots of ignorant people" the ones who
would consider what I mentioned.

No, whether it is usable as a C99 implementation depends to a much greater
extent than you appear to realise on whether it is one.

I do realize that, but there are other factors. Recall our talk about
the conforming implementation that erases all the files in the hard
disk because of UB... So much for usability!

(That should, of course, have been "The judge will not be impressed by
Company B's claim".)


Right. Company B has no case. Their opinion that gcc conforms to C99 is of
no merit, and so their suit against Company A fails.

Likewise, your opinion that gcc conforms to C99 is of no merit.

I've never said that that's my opinion. Not once, not ever.

Yet. It may
become so, and we all hope it does - but it isn't there yet.



Whether or not you have denied it is of little consequence, and I can't be
bothered to find out whether you have unequivocally denied that precise
claim. What matters is that the claim is true - gcc does not conform to
C99. I have no doubt that they would like to conform to C99, and they have
gone a long way towards conformance. Clearly there are problems. I have no
doubt that they would conform to C99 now if they could do so without
breaking anything, and they are very bright people so no doubt they will
find a way in due course. But they are not there *right now*.

Agreed.



Yes, we were - among other things.


No, sir. We were talking about what *you* consider to be a C99
implementation.

See, that's the consequence of snipping! Here's the context
restored:

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

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

) Those are weasel words, and they don't get around the fact that gcc
) doesn't conform to C99.

So we /were/ talking about at what number of features people would
consider an implementation to be a C99 implementation.

And yet they aren't very accurate, are they? Can I suggest that we stick
not to what you think most people think, but rather what you yourself
think? You're not good at most - for example, you think most people
develop in C99 - so it might be better to stick to the facts.

But, as we've learned, it's rather unattainable to illustrate the
facts for what we're discussing here.

I am content with my snippage on that occasion. You made a claim of
falsehood that you could not back up. It is quite proper for people to pay
no attention to such claims.

Neither could you back up what you claimed, so I did not feel the need
to support the claim of falsehood, but simply to point out its
falsehood.

Sebastian

 

[jameskuyper]

It might be a strong evidence to you. But, unfortunately, not everyone
of us has the fortune of being able to see exactly what you see, so
the rest of us have the inconvenient need to either believe you're
wrong, or go find out ourselves, possibly ending up realizing that you
were wrong in the first place.

I get it! You misunderstand the term "eye witness evidence" as meaning
evidence that you yourself have witnessed. Not, the term is not so
restricted.You are responsible for judging the quality of eye-witness
evidence witnessed by other people's eyes. If you choose to discount
any such evidence that doesn't match your own preconceptions, that's
your choice to make, but it's one that leaves you in a solipsist
fantasy world.

Since the standard does not define the term "non-conforming C99
implementation," then the meaning of that term is subject to what
everyone of us thinks about it.

Not really - the definition of conforming C99 implementations implies,
by simple negation, what a non-conforming C99 implementation is.

 

[Ben Bacarisse]

I don't need any evidence, because I know I'm right.

I suspect (though I am not sure) that you did not really intend to
write that. Maybe a "more" or "other" got dropped?

<snip>

 

[Ben Bacarisse]

Ben Bacarisse said:


I *did* mean to write that,

OK, but did you mean what is says? Maybe just the first "I" needed
stressing? I still can't work it out.

but perhaps an expansion of my point would be
useful.

Putting the remark back into context:

Yes, I read the context. Then I re-read the context. Then I saved
the draft of my post and read though the thread a bit more (because I
have not been following it). Since I've got the wrong end of the
stick in the past I was cautious; but I just could not see how the
context (which seemed to be all about your evidence *for* being right)
altered the rather odd remark.

I had said:
"But the fact that I have never seen [a C99 installation], in circumstances
where I would *expect* to see one if they were commonplace, is strong
evidence that they are not as common as you would have us believe."

Sebastian replied: "It might be a strong evidence to you."

Now, I *know* that C99 installations [defining "installation" as "instance
of a C99 implementation installed on an actual machine"] are not as common
as Sebastian would have us believe because, if they were, I *would* have
seen at least one by now.

Isn't that the evidence?

Let's just play with some numbers, on the basis that C99 is - well, never
mind "most". Remember the claim: "people starting to write new apps
usually choose C99". For something to be "usual", it has to be more common
than the alternatives, but let's just say that Sebastian has a point if
even a paltry *quarter* of installations are C99 installations.

If that is so, and if they are evenly distributed among the C community (an
assumption, admittedly, but not a desperately unreasonable one by any
means) then what is the probability that a reasonably experienced C
programmer who gets around a bit has never seen a C99 installation?

Number of Probability that none is a C99
installations installation, given that 25%
observed of installations are C99
10 0.056313514709472656
20 0.003171211938933993
30 0.000178582090170015
40 0.000010056585161637
50 0.000000566321656427
60 0.000000031891562929
70 0.000000001795925998
80 0.000000000101134905
90 0.000000000005695262
100 0.000000000000320720

I've seen a great many more than 100 C installations in the last two or
three years. If C99 made up even as few as 25% of installations, the
probability of my not seeing any would seem to be approximately one in
three million million. The probability of my winning the UK lottery (if
only I could be persuaded to buy a ticket, which I can't because it's such
a ludicrously stupid idea because the chance of winning is so low) would
be over two hundred thousand times greater.

OK, I will just have to accept that I have misunderstood (and that I
still don't know what you mean) since this just looks like the
evidence that causes your belief. I looks like you meant "I know I am
right (I have the evidence of my own observations)" but it appears not.

On this basis, I am prepared to stand by my claim that I know I'm
right.

That was not in doubt. I would not have said a word if you had simply
said "I know I am right". I would have assumed you knew you were
right due to the weight of evidence you had acquired (both first- and
second-hand). Would it stand as a sig, or does the context somehow
make it mean something else?

 

[Flash Gordon]

Yes, I accept that you would not consider a number smaller than (or
even close to) 10 to be "many." In fact, I accept that you consider
whatever you claim to consider. Whether those considerations are
accurate is another matter.

You seem to be incapable of understanding a simple argument. In general
a number smaller than 10 is not considered to be "many" and as there are
fewer than 10 C99 implementations there are not many C99 implementations.

Not the same thing.

Since there *are* fewer than 10 C99 implementations it is a ogical
conclusion.

Yes, I didn't produced any evidence. You have the evidence that "more
than two people in this thread" are also in agreement with you. But it
would take more than two people in this thread to consider any such
evidence to be relevant, so it is not much of an evidence.

We also have the other evidence which you claim is not evidence. This
claim on your part is evidence that you do not understand what the term
"evidence" actually means.

Google researches can't prove this.

I have not claimed it proves it. However, it *is* evidence and
reasonable people accept the possibility that what evidence suggests is
actually true especially when there is no counter-evidence available.

You have not presented such evidence. The fact that it is not the
default doesn't mean they don't consider it to be suitable for use as
a C99 implementation. They also have a C89 implementation, and it also
isn't the default. Do they not consider GCC to be suitable as a C89
implementation? I wouldn't think so.

They state EXPLICITLY that the reason GNU89 is not the default is that
the C99 implementations is not finished. To understand my point you do
have to understand that there is actually a relationship between GNU89
and C89 and another relationship between GNU99 and C99. However, you
seem to have difficulty understanding the relationships between things.

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

You forgot the words "in Windows" in that last sentence.

No, I didn't. A piece of evidence on the state of one part of a field is
evidence of the state of all of the field. The more areas of the field
you have evidence from the more confident you can be about the state of
the entire field.

The above applies to the fields farmers use, scientific fields,
engineering fields, computer fields, magnetic fields and all other
fields I can think of at the moment. So it applies to this discussion.

And yes,
perhaps most new C development _in Windows_ is not done in C99, but
that wasn't what you objected to; it was to what I said about MSVC not
being the only C compiler on Windows.

Your point that other compilers are available for Windows is completely
irrelevant to the main argument as to which version of C most people are
using. That is what is proved by this point. So it is YOUR claim that is
irrelevant and the claim I've made that you have now accepted is what
shows it to be irrelevant.

You agreed that MSVC wasn't the only C compiler on Windows, and then
you claimed that I was wrong. That *is* self-contradiction.

Your first statement in the block of quote a little bit above was
disputing Richard's claim that most people don't have a C99
implementation. Your refutation was wrong.

No, I haven't been presented with such evidence.

It has been presented, the problem seems to be that you don't know what
the word "evidence" actually means. I'll give you a clue, it does not
mean conclusive proof otherwise there would be evidence to support the
"Laws of Thermodynamics".

It doesn't mention that C99 support is broken; it mentions which
features of C99 in GCC are broken. If you believe I'm wrong, please
provide a quote from the page where they explicitly state what you're
claiming.

So you claim that if A is made of B, C and D knowledge that C is broken
is not evidence that A (of which C is part) is not broken.

OK, I've got this car which is not broken that I would like to sell you.
You can tell it isn't broken because the horn works!

The last sentence is wrong.

Where is your evidence for this wild and unsupported claim? It is safe
to assume you are wrong since there is no evidence to support it.

But, what does that have to do with GCC
users having access to other compilers?

It is pointing out that not everyone being like me (which I agree is
true) is not evidence that gcc users have access to some other compiler
that *is* a C99 compiler.

I.e. you completely failed to refute my point.

Really?

Yes. Oh, and the reason a lot of people I have seen on this group have
been aware of C99 is that they were told about C99 *on* this group!

In my case, the only C developers I have come across who have
heard of K&R before I have mentioned it to them are people on this
group. In fact, most people would hear about K&R and think about the
book (most likely the 2nd edition, actually), instead of the ancient
language.

I did not say that I was referring to the language defined by the first
edition of the book. I said K&R. OK, perhaps I should have spelled out
their names in full and said that what versions of their book people
know about was irrelevant.

Oh, and don't forget that the 2nd edition of the book K&R is about the
language as defined by C89 (this time I do mean the ANSI standard rather
than the technically identical ISO standard that followed). So someone
who knows the 2nd edition of the book knows C89, so more people knowing
about the book than knowing C99 implies that more people will be
programming in C89 than C99 because the only version of C they know is C89.

So we shall.


Actually, it's only common sense.

There has been a lot of suggestion that C is mostly used in embedded
programming these days, so considering it to be a special case without
presenting a good reason is not sensible. Even if it is not used more in
embedded programming than non-embedded it is certainly used a *lot* as
evidenced the number of processor manufacturers who release a C compiler
for their embedded processors.

Above is eye-witness evidence in support of this position. However, you
don't understand the term so it is no wonder you did not comment on it.

I have never said that that's my definition of a C99 implementation.

No, you completely refuse to define it. However, it seems to be that if
it is vaguely close to conforming then it is one. Most C90+extensions
compilers are closer to conforming to C90 than GNU is to conforming to
C99 (most extensions are written so as not to break conformance) so by
your definition most C90+extensions compilers are C90 compilers. So
their use is evidence by your definition of what a Cxx compiler is that
C90 is used.

I've never made an argument saying that people are working in C90 +
extensions.

No, however *I* am arguing that use of C90+extensions is use of C90 by
your terms and that most people are using C90+extensions.

Agreed.

In that case either:

1) gcc is *not* a C99 compiler so people using it are not using C99 and
as people using gcc seems to be your main argument for the popularity of
C99 your position is completely untenable.

Or:

2) The evidence I presented about people using C90+extensions (e.g.
Using gcc in its default mode) is evidence of people using C90.

Could you point me to that evidence?

Most new posters to this group who use gcc use it in its default mode as
shown by their posts. Also it is the mode that GNU encourage so it is
likely that most GNU SW (and there is a lot written by a lot of people)
is developed in this mode.

You did claim that most new C development is in C90 + extensions. Your
words were

"There, you now have a reasoned argument as to why most new C
development is in C90 + extensions and *not* in C99 - bits not
implemented or broken."

OK, my memory is not perfect. Possibly I did say that.

However, we have now established that by your definition that woud count
as most C development being in C90 rather than C99.

Obviously.

Well, since that is the mode most people use because that is the mode
most compilers default to...

Yes, safe, though I wouldn't bet on it...

Well, feel free to bet against the evidence. It must make you popular
with book-makers.

No, all you are doing is repeatedly claim to have some evidence which
(whether it's true or not) you are not presenting.

The problem here is that you do not understand what the term evidence
means. Well, not the only problem, another problem is that you do not
understand reasoned argument.

I'm not sure which arguments you're talking about, but the ones in
this thread certainly haven't proved anything.

You need to learn what the word "argument" means.

I'll help, here are some quotes from dictionaries.

argument
2
a.A course of reasoning aimed at demonstrating truth or falsehood...
b.A fact or statement put forth as proof or evidence; a reason...
c.A set of statements in which one follows logically as a
conclusion from the others.

evidence
1. A thing of things helpful in forming a conclusion or judgement...
2. Something indicative; an outward sign...

No, they don't. Again, if you believe I'm wrong, please provide a
quote from the page where they explicitly state what you're claiming.

Here is the quote for you. "broken". It appears several times on the page.

Oh, and do you accept that the vast majority of implementations are C90
implementations even if they are also C99 implementations?

Agreed.

Well, that's gcc rules out as a C99 implementation.

The fact that I don't refute it doesn't mean I accept it. Though in
this particular case, it's true what you say about GCC's info pages
saying that the C99 standard is not fully supported. But that's
obvious--I don't need to further comment on it.

So we have it not fully supported and broken. Sounds like it is not
something that cannot be considered a C99 implementation to me.

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.

No, you haven't. Again you're making wild claims about having some
evidence, and it's only reasonable to assume you don't have it since
you don't present it.

It has been presented, you just don't understand what the word
"evidence" actually means.

It's not an evidence, as I pointed out, but it _is_ a strong clue.

More evidence that you don't know what the word "evidence" actually means.

No, I didn't.

All the evidence points towards it. Of course, as you don't know what
the word evidence means...

There are probably more non-C99 than there are C99 compilers, but the
reason I said it isn't very likely that C99 will not be available
because of management specifying which compiler to use is that it has
nothing to do with management specifying which compiler to use!

Can you not see that if management specify "use compiler X" then that
means that compiler Y is not available to those programmers?

You only made a comment about C99's availability. It had nothing to do
with management specifying which compiler to use.

It does. Anything management forbids you from using is not available to you.

Not if they're not aware of any free C90 implementation, which was the
point in the first place anyway.

Awareness of C90 is irrelevant. Re-read the above and this time try to
actually understand it. You probably need to learn what "the aw of
averages" means though.

Actually, it is simple probability theory. If there are a lot more items
of type A in the bag than there are items of type B then someone is more
likely to select an item of type A. There are a lot more compilers that
support C90 than compilers that support C99 so a randomly selected
compiler is more likely to support C90 than C99. When you add the fact
that most C99 compilers are also C90 compilers the odds of *not* picking
a compiler that supports C90 drop to almost zero.

Your analogy has nothing to do with being or not being aware of free
C90/C99 implementations.

It has everything to do with what the compiler selected is likely to
support *unless* the compiler is selected specifically to support a
specific version of the standard.

Whether the compiler they're using provides C90 conformance but not
C99 conformance does not relate to being or not being aware of free
implementations.

No, but it very strongly relates to whether they are using a C99 compiler.

So you accused me of being wrong,
Yes.

and then make a completely unrelated
comment (by your own admission).

No, it is relevant to the specific point you made. A point about which
you were wrong. You are wrong to think that a C99 implementation is
likely to be of lower quality than a C90 implementation. The reason
being that the C90 implementation might have stopped development 20
years ago when various compiler technologies were less well understood
where-as a C99 implementation has definitely been under development
since the late 90s.

That annuls both your claim about me
being wrong AND your claim about me talking rubbish. It also raises
some interesting questions as to what goes through your mind when you
make these replies.

No, it shows that you have not understood the point.

No, you not being able to prove that *you*'re right makes it safe to
assume that you're wrong.

The same argument applies more strongly to you. You have not even
presented any evidence, not even low quality evidence.

Again you're claiming to have some kind of evidence, which you have
not presented. You only made some claims about the reasons people
would use C99, with NO supporting facts or evidence.

Incorrect. A number of people have presented evidence. You just don't
understand what the word means.

You made no rebuttal; you simply talked about your C development
career.

Well, we have already established that you don't know what eye-witness
evidence is.

The three points were, again: of the people who can afford a C99
implementation, not everyone likes them; of those who do, not everyone
can make the decision of buying them; and of those who do, not
everyone wants to spend money one them. Then I say that those points
are equally applicable to an implementation of any standard, and you
refute to it by saying that there is only one compiler that supports
C99 but not C90. I don't see how you can link these things together.

Buy some new glasses. Unless they are forced to use a pre-ANSI compiler
(which obviously does not support C99 since C99 is a long way post-ANSI)
or they are forced to use the one and only compiler that supports C99
but not C89, then they are forced to use a compiler that definitely
supports C89. Note that if they are forced to use gcc they are forced to
use a compiler that supports C89 as just *one* example.

<snip>

What if they can't afford them? What if they don't like them? What if
they can't make the decision of buying them? What if they don't want
to spend money on them? (In case you don't realize, these are the
points being discussed.)

I'm talking about the compiler THEY ALREADY HAVE!

If they don't have a compiler and they cannot obtain one then they
cannot compile their code anyway so it is irrelevant.

Now try re-reading the above and actually understand it rather than
doing what I can only assume is deliberately failing to understand it.

From that point of view, it is related, but it fails to explain why
the points made about C99 aren't equally applicable for an
implementation of any standard.

It is ENTIRELY relevant. There are more C89 compilers than C99
compilers, therefore throw all the C compilers in to a bag and pick one
out at random and it is more likely that you will get a C90 compiler
than a C99 compiler. Therefore any reason for selecting a compiler other
than for conformance to a specific standard is more likely to select a
C89 compiler than a C99 compiler.

It doesn't, since hardly relates to what was being discussed, and
doesn't give any arguments against it.

Incorrect. It is entirely relevant to all your claims that reasons why
one might not end up with a C99 compiler as less likely to apply to C90.
See above.

Yes, in general, considering my limited knowledge about their
requirements. But I never claimed that Richard's work is for embedded
systems.

I still have not said you made that claim.

So you're assuming that I implicitly claimed that Richard's work is
not for embedded systems because (a) I make the assumption that they
would most likely be able to accept C99 code, and (b) because I
accepted that embedded systems would be a place where C90 would be
more advantageous. No, you misinterpreted my words; I never made that
claim, neither implicitly nor explicitly. You'd be better off not
assuming implicit claims that I have not explicitly stated.

It is the logical conclusion.

A leads to NOT B.
You claim B, therefore you are assuming NOT A.

If Richards customers are using his code for embedded systems then C99
is NOT acceptable.

You claim that C99 is likely to be acceptable.

For you claim to be true Richards customer cannot be using his code for
embedded systems (because if they were then C99 would not be acceptable.

Neither did I claim to *know*; I claimed to *think* that, most
*likely*, and considering my limited knowledge about their
requirements, they would find C99 acceptable.

Your knowledge is based on what Richard has said, and Richard has said
that C99 would be likely to be rejected. So you seem to be claiming to
know more about his customers than he does.

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

You have no evidence since you're only making an inaccurate assumption
about an implicit implication on their website. I, on the other hand,
am only pointing out what they have *explicitly* stated. Therefore, my
point is stronger.

They explicitly state it is broken on their web site. This *is*
evidence. It may not *prove* the point, but it *is* evidence.

Oh, and I have done a small amount of work on the GNU tool-chain, so to
a very small degree I am one of the developers. I would not claim to
speak for the majority, but...

 

[s0suk3]

(e-mail address removed) said:





I don't need any evidence, because I know I'm right.

But the rest of us don't :-( Moreover, some of us believe you're
wrong.

The strength of
eye-witness evidence depends on one's assessment of the character and
reliability of the eye-witness. If one thinks he's a trustworthy person
who will only tell about what he saw (i.e. not make stuff up for whatever
reason), then one will tend to believe what he says about what he saw.

There are some subscribers to this group who wouldn't trust me to get the
day right - but since they can't actually read with any degree of
comprehension, I'm not overly concerned with any lack of faith they might
express in my eye-witness account of the paucity of C99 installations, and
I probably wouldn't even get to read such an expression anyway.

I'm not sure who you mean by those subscribers who you claim can't
read with any degree of comprehension, but the interesting point is
*why* you would claim they can't read with any degree of
comprehension. If it is because they don't believe in your so-called
eye-witness evidence, I would argue they can read with a higher degree
of comprehension than anyone who would believe in your so-called eye-
witness evidence, since it is potentially unsafe and stupid to believe
in anyone's so-called eye-witness evidence without having actually
seen that so-called eye-witness evidence.

Nor am I concerned over-much with your inability to accept my eye-witness
account. If you don't believe me, fine, that's your problem.

As previously mentioned, believing in someone's so-called eye-witness
evidence is potentially unsafe and stupid if one hasn't actually seen
that so-called eye-witness evidence.

Most people know full well that there's hardly any C99 conformance out
there in the field, so those who are maximally or at least very highly
concerned with portability will necessarily stick to the common subset of
C90 and C99.

I think people who are highly concerned with portability can stick
with the current standard. If they need more portability in terms of
cross-machine compiler availability than C99 offers, well, they can go
with C90, but that isn't normally the case.

I agree that not everyone has the wit to understand what "reported
observations" means.

Yes, especially when those "reported observations" haven't actually
been reported.

No, they don't, because you don't understand what you're observing.

You have not enough knowledge about me to know what I understand or
not.

<snip>

So far so good.

By "conforming C99 implementation", I mean the same thing the C99
Standard does: [...]
So anything that matches the description given by C99 of a conforming
implementation is necessarily a conforming C99 implementation.

So far so good.

Since the standard does not define the term "non-conforming C99
implementation," then the meaning of that term is subject to what
everyone of us thinks about it.

Yes, you can interpret "non-conforming C99 implementation" any way you
like. That doesn't necessarily make your interpretation useful or
meaningful to others.

Funny, because the only person who has objected about the usability of
that term so far is you.

No, it's a newsreader. It's not a C99 implementation, any more than a
banana is a C99 implementation.

I agree, but that's not what you mentioned earlier.

I have seen no sign of this.

That's because of your lack of a notion of reality.

On the contrary, the claim had already been backed up with research by a
number of people other than myself. I felt no particular need to add to
their number, but I could have done so, had I chosen.

The claim was:

"But if this newsgroup is any guide, by far the majority of people who
use the term "C99 implementation" use it to mean a /conforming/ C99
implementation - and apart from Usenet, ISO committee meetings, and
the odd Web page the term is rarely, if ever, used at all."

No research has been done to back this up, and common sense stands out
against it.

The trouble with pointing out the "falsehood" of something that is pretty
obviously true is that, unless you can demonstrate to other people's
satisfaction that you're right, people tend to think you're talking
nonsense. For example, it is pretty obviously true that the world is
approximately spherical - someone who claims that that observation is
false is setting himself up to be thought a crank unless he can provide a
rigorous demonstration that he's right.

Sure, it's obviously true that the world is (approximately) spherical.
But that isn't nearly related to this case since your claim is not
obviously true, and it would take some (corrupted) lawyer work to back
it up.

Now, the claim "But if this newsgroup is any guide, by far the majority of
people who use the term "C99 implementation" use it to mean a /conforming/
C99 implementation - and apart from Usenet, ISO committee meetings, and
the odd Web page the term is rarely, if ever, used at all" is not quite as
self-evident as the roughly-spherical nature of the world, but it's pretty
darn obvious to C programmers. If you want people to believe that the
claim is false, you will need to find a way to demonstrate this.

Obviously not all C programmers agree with that, as this thread shows.
It's true that some people in this newsgroup use the term that way (as
we've seen in this thread), but some others don't (as we've also seen
in this thread). Even if we could prove how the majority of people in
this newsgroup use the term, it wouldn't be very useful, since the
people in this newsgroup don't constitute a reasonable number of C
programmers in the globe in order to make a relevant argument about
how most C programmers use the term.

Sebastian

 

[Keith Thompson]

(e-mail address removed) said:

(e-mail address removed) said: [...]
Since the standard does not define the term "non-conforming C99
implementation," then the meaning of that term is subject to what
everyone of us thinks about it.

Yes, you can interpret "non-conforming C99 implementation" any way you
like. That doesn't necessarily make your interpretation useful or
meaningful to others.

Funny, because the only person who has objected about the usability of
that term so far is you.

Wrong. "In the context of a debate over whether or not compilers that fully
conform to the C90 standard are overwhelmingly more common than compilers
that fully conform to the C99 standard, using a term that doesn't clearly
identify the compiler as conforming to at least one of those two standards
is not very useful." - James Kuyper, in message
<dcf74a6b-1c74-46c1-acaa-5a7f961951ea@l42g2000hsc.googlegroups.com>

[...]

And: "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." - me, in message
<[email protected]>.

Richard, I suggest that arguing with s0suk3 is a waste of time and
bandwidth. He's not likely to acknowledge that you're right no matter
how much evidence you present.

 

[Kenny McCormack]

Richard, I suggest that arguing with s0suk3 is a waste of time and
bandwidth. He's not likely to acknowledge that you're right no matter
how much evidence you present.

Looks like you mistyped: because you never are.

HTH - HAND.

 

[Randy Howard]

[lots of snipping here...]

For example, you could tell us whether you've actually encountered any C99
installations in the field (and note that I do not mean "not-quite-C99"...

... I have been using C since the summer of 1989. Obviously *nobody*
encountered any C99 implementations in the period from 1989 up to the
point where ISO finalised the Standard in late 1999, but I report that I
have never observed a single C99 installation, *ever*, including the period
from 1999 to the present day. Not once. Every conforming C installation I
have seen has been C90-conforming but none of them has been C99-conforming.

Have you any counter-examples whatsoever? Have *you* ever encountered a
conforming C99 installation? Even one?

The above pretty much sums up what I've seen as well. I too have had
this sort of discussion -- on Usenet, email, in person with other
developer friends, and in production software development shops.
Invariably someone will say something like "Well, gcc is available
for pretty much every platform, and has -std=c99 !!!"

Then I or someone else points them at the gcc URL that shows all the
areas where gcc is /not/ a complete implementation of C99 and they
are crestfallen. Then they try to argue that "we" don't need those
other features anyway for various reasons, and ... <insert death
spiral here>

So, what happens when a portion of gcc users start going to LLVM?
Last I checked, they use the front end of gcc to support C and C++,
so I guess it doesn't change.

But, we can't pretend that gcc is what determines C99 availability
The vast majority of software development done for hire involves a
Windows platform of some flavor. Like it or not, it still has a huge
market share. Of those shops, the few neanderthals that are still
using C for work other than system tools, internals or drivers are
using some variant of MSVC the majority of the time, which /clearly/
is not a C99 compiler and likely never will become one.

What about Open Watcom, which someone here in clc claimed back in
2007 was "working on c99 compliance"? Well, looking at the Open
Watcom FAQ, today, it says:

<quote from their Wiki>
Is the Open Watcom compiler C99 compliant? 

No, not fully. The most-used parts of the standard (ISO/IEC 9899
-1999 standard, also adopted by ANSI) have been implemented, and
there is an ongoing effort to add more. Full implementation may be
achieved at some point in the future. For now, the implemented
parts of C99 can be enabled via an undocumented switch.
<end of quote>

I especially like the "enabled via an undocumented switch" part.


Finally, there are repeated claims that "I heard of a commercial
compiler from <XYZ Corporation> that claims to be fully conformant
with C99". I've even seen lists of them posted in various places.
But, to get back to Richard's question above, I have never seen or
heard any C developer claim "I am currently using a compiler from
<XYZ Corporation>, and it appears to be fully C99 conformant, as
advertised."

Apparently, as previously suggested, they are rumored to exist, but
nobody has ever seen one of these endangered species in the wild. If
they have, they're under such a tight NDA that they can't talk about
them publicly.

Taking a slightly different tack than Richard's question, can anyone
post a piece of C source code using a reasonable selection of "new
for C99" features (which must include at least VLAs) which will
compile and work equivalently across more than one C compiler, and
for more than one operating system? A set of test cases to validate
it is working equivalently on each would be worth bonus stars next to
your name.

If such code can be written, and people here can compile it and see
it run on multiple platforms and compilers, that would be a much more
convincing argument than "I heard it from a friend, who heard it from
a friend, that somewhere there is a real C99 compiler, so we should
all feel free to use C99 extensions".

 

[jameskuyper]

Randy Howard wrote:
....

But, we can't pretend that gcc is what determines C99 availability
The vast majority of software development done for hire involves a
Windows platform of some flavor. Like it or not, it still has a huge
market share.

Microsoft has a huge share of the desktop market. However, there's a
lot more to the C programming world than the desktop market, and
Microsoft's share of the mainframe and embedded markets, for instance,
is much smaller (non-existent?). The embedded market, in particular,
is an area where C's simplicity and correspondingly small size gives
it a bigger advantage over C++ than in other environments, which has
made embedded processors one of the main areas in which new C
development occurs. There are many different types of embedded
processors. Each desktop CPU contains many different embedded
processors. I can't vouch personally for the truth of the claim that
more C code is written nowadays for embedded processors than is
written for all other purposes combined; but I can't think of any
reason to disbelieve it, either. Can you?

 

[jacob navia]

[lots of snipping here...]

For example, you could tell us whether you've actually encountered any C99
installations in the field (and note that I do not mean "not-quite-C99"...

... I have been using C since the summer of 1989. Obviously *nobody*
encountered any C99 implementations in the period from 1989 up to the
point where ISO finalised the Standard in late 1999, but I report that I
have never observed a single C99 installation, *ever*, including the period
from 1999 to the present day. Not once. Every conforming C installation I
have seen has been C90-conforming but none of them has been C99-conforming.

Have you any counter-examples whatsoever? Have *you* ever encountered a
conforming C99 installation? Even one?

The above pretty much sums up what I've seen as well. I too have had
this sort of discussion -- on Usenet, email, in person with other
developer friends, and in production software development shops.
Invariably someone will say something like "Well, gcc is available
for pretty much every platform, and has -std=c99 !!!"

Then I or someone else points them at the gcc URL that shows all the
areas where gcc is /not/ a complete implementation of C99 and they
are crestfallen. Then they try to argue that "we" don't need those
other features anyway for various reasons, and ... <insert death
spiral here>

The features that gcc is missing are a few esoteric
features. Most of C99 is there. Using this same criteria
there is only two C++ compilers in the world:
Comeau and Edison Design Group front end. All others, gcc and
MSVC included fail to implement the FULL C++ standard.

So, what happens when a portion of gcc users start going to LLVM?
Last I checked, they use the front end of gcc to support C and C++,
so I guess it doesn't change.

But, we can't pretend that gcc is what determines C99 availability
The vast majority of software development done for hire involves a
Windows platform of some flavor. Like it or not, it still has a huge
market share. Of those shops, the few neanderthals that are still
using C for work other than system tools, internals or drivers are
using some variant of MSVC the majority of the time, which /clearly/
is not a C99 compiler and likely never will become one.

I am one of those "neanderthals" as you call the (apparently) stupid
people that use the C language.

Your attitude is very representative of the people that
abound here. If I use a simple language and like that
conceptual simplicity, I am qualified as a neaderntal by
all the wanabees that believe that a huge increase of complexity
is the solution to everything.

Yes, there are many people that think like you. And there are
billions of flies that eat shit. Not a reason, (for me) to
follow their tastes.
*But coming back to C99, there is
(1)
IBM xlc compiler for Power PC, for mainframes and all other
IBM environments that implements C99.
(2) Intel compiler for the windows environment implements
C99
(3) Sun compiler implements C99.
(4) There are some implementations that aren't *fully* there,
but they have implemented most of the essential features of C99.
Note that according to your criteria gcc is not a C++ compiler
either.

[snip rest of drivel]

 

[Randy Howard]

Randy Howard wrote:
...

Microsoft has a huge share of the desktop market. However, there's a
lot more to the C programming world than the desktop market, and
Microsoft's share of the mainframe and embedded markets, for instance,
is much smaller (non-existent?).

You seem to be conveniently forgetting all the Windows servers out
there as well.

The embedded market, in particular,
is an area where C's simplicity and correspondingly small size gives
it a bigger advantage over C++ than in other environments, which has
made embedded processors one of the main areas in which new C
development occurs.

Sure. What this has to do with the existence of (or lack of) C99
compilers, I'm not quite sure.

There are many different types of embedded
processors. Each desktop CPU contains many different embedded
processors. I can't vouch personally for the truth of the claim that
more C code is written nowadays for embedded processors than is
written for all other purposes combined; but I can't think of any
reason to disbelieve it, either. Can you?

I fail to see what bearing all this has on C99 compiler availability.

 

[Randy Howard]

[lots of snipping here...]

For example, you could tell us whether you've actually encountered any C99
installations in the field (and note that I do not mean "not-quite-C99"...

... I have been using C since the summer of 1989. Obviously *nobody*
encountered any C99 implementations in the period from 1989 up to the
point where ISO finalised the Standard in late 1999, but I report that I
have never observed a single C99 installation, *ever*, including the
period
from 1999 to the present day. Not once. Every conforming C installation I
have seen has been C90-conforming but none of them has been C99-conforming.

Have you any counter-examples whatsoever? Have *you* ever encountered a
conforming C99 installation? Even one?

The above pretty much sums up what I've seen as well. I too have had
this sort of discussion -- on Usenet, email, in person with other
developer friends, and in production software development shops.
Invariably someone will say something like "Well, gcc is available
for pretty much every platform, and has -std=c99 !!!"

Then I or someone else points them at the gcc URL that shows all the
areas where gcc is /not/ a complete implementation of C99 and they
are crestfallen. Then they try to argue that "we" don't need those
other features anyway for various reasons, and ... <insert death
spiral here>

The features that gcc is missing are a few esoteric
features. Most of C99 is there.

So you readily admit that it is not a complete C99 compiler. I'm
still waiting to hear anyone list a specific C compiler that /is/ a
full C99 implementation that they have actually used, not just heard
of somewhere.

I am one of those "neanderthals" as you call the (apparently) stupid
people that use the C language.

I think you misread the above. I still use C every day. I don't use
it for developing GUI applications though. I use it for systems
level code. Some people still use assembler to write word processors
probably. They're not stupid, they're just into self-mutilation.
The above was more to do with using the right tool for the right job.

Your attitude is very representative of the people that
abound here. If I use a simple language and like that
conceptual simplicity, I am qualified as a neaderntal by
all the wanabees that believe that a huge increase of complexity
is the solution to everything.

Again, you misinterpreted the above, but either way, it has nothing
to do with the existence of C99 compilers.

I notice that you passed on the opportunity to demonstrate the
portability of C99 by posting some code that will compile on multiple
compilers that claim to support it.

 

[jameskuyper]

You seem to be conveniently forgetting all the Windows servers out
there as well.

No, I'm just remembering all of those Unix and Unix-like servers out
there. I can't give you any solid numbers for market shares - do you
have any?

Sure. What this has to do with the existence of (or lack of) C99
compilers, I'm not quite sure.

Nothing - it has only to do with your comment that "The vast majority
of software development done for hire involves a Windows platform of
some flavor." As you may have noticed, I'm arguing on the same side as
you with respect to the main issue; it's only this side topic where
I'm disagreeing with you.

I'm strongly in favor of not starting off-topic threads, and I'm
strongly in favor of re-directing them to a more appropriate forums
whenever someone does start an off-topic thread. However, thread
drift is a fact of usenet life. Once a thread has become well rooted
in one particular set of usenet groups, it's not really feasible to
remove it from any one of those groups. Follow-ups are often ignored,
and in any event some of the participants might be monitoring the
discussion only through the group(s) it has been removed from.

The best way to avoiding a discussion of whether or not Microsoft
dominates the C programming world is by not mentioning the idea in the
first place.

 

[jacob navia]

[lots of snipping here...]

For example, you could tell us whether you've actually encountered any C99
installations in the field (and note that I do not mean "not-quite-C99"...
... I have been using C since the summer of 1989. Obviously *nobody*
encountered any C99 implementations in the period from 1989 up to the
point where ISO finalised the Standard in late 1999, but I report that I
have never observed a single C99 installation, *ever*, including the
period
from 1999 to the present day. Not once. Every conforming C installation I
have seen has been C90-conforming but none of them has been C99-conforming.

Have you any counter-examples whatsoever? Have *you* ever encountered a
conforming C99 installation? Even one?
The above pretty much sums up what I've seen as well. I too have had
this sort of discussion -- on Usenet, email, in person with other
developer friends, and in production software development shops.
Invariably someone will say something like "Well, gcc is available
for pretty much every platform, and has -std=c99 !!!"

Then I or someone else points them at the gcc URL that shows all the
areas where gcc is /not/ a complete implementation of C99 and they
are crestfallen. Then they try to argue that "we" don't need those
other features anyway for various reasons, and ... <insert death
spiral here>

The features that gcc is missing are a few esoteric
features. Most of C99 is there.

So you readily admit that it is not a complete C99 compiler. I'm
still waiting to hear anyone list a specific C compiler that /is/ a
full C99 implementation that they have actually used, not just heard
of somewhere.

I am one of those "neanderthals" as you call the (apparently) stupid
people that use the C language.

I think you misread the above. I still use C every day. I don't use
it for developing GUI applications though. I use it for systems
level code. Some people still use assembler to write word processors
probably. They're not stupid, they're just into self-mutilation.
The above was more to do with using the right tool for the right job.

Your attitude is very representative of the people that
abound here. If I use a simple language and like that
conceptual simplicity, I am qualified as a neaderntal by
all the wanabees that believe that a huge increase of complexity
is the solution to everything.

Again, you misinterpreted the above, but either way, it has nothing
to do with the existence of C99 compilers.

I notice that you passed on the opportunity to demonstrate the
portability of C99 by posting some code that will compile on multiple
compilers that claim to support it.

#include <stdio.h>

int main(int argc,char *argv[])
{
int table[argc];

printf("C99 lives with a table of %d integers\n",argc);
}

VLAs are supported by
gcc
IBM xlc
Sun compiler
Intel C99 compiler
lcc-win


I note that you skipped THE LIST OF C99 COMPILERS I WROTE.

Besides, I use C for interfacing directly with the windows API
in my GUI programs. It has several advantages, and the biggest
one is that it is PORTABLE from windows 98 to windows VISTA.

You can't say the same from other combinations of libraries
and OSes.

 

[Randy Howard]

No, I'm just remembering all of those Unix and Unix-like servers out
there. I can't give you any solid numbers for market shares - do you
have any?

Not directly. Looking through half a dozen "jobs" sites for software
dev jobs shows a preponderance of positions in the wintel space
though. Not one word about mainframes, and a few embedded jobs. A
lot web, and database jobs that could be on any platform, and heaps
and heaps of .NET and MS-specific acronym jobs. Not authoritative,
but enough to show it's at least a major player as far as programmer
headcount, imo. ymmv.