Storgae durations

[jameskuyper]

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.

The last time I did a serious job search, it was pretty difficult to
distinguish jobs involved C programming from jobs involving C++. Many
search engines would produce the same results for "C" and for "C++".
Many of them would return every job using any word that started with
"c", regardless of length. No search engine I tried gave me an easy
way to search for "C", excluding "C++". Many employers would use the
term "C/C++", when what they actually needed was either a C programmer
or a C++ programmer, but they didn't need someone skilled in both
languages (often the employers themselves were unaware of the fact
that they didn't need someone with both skill sets). Have the newer
sites made any improvement in this regard? If not, it could be very
difficult to use job listings to distinguish a Microsoft "C"
predominance from a Microsoft "C++" or "C#" predominance.
I have decades of paid C programming experience, but only a couple of
weeks of very-recently acquired paid C++ programming experience, and
very little unpaid experience in C++, so this will be an important
issue in my next job search.

 

[jameskuyper]

Randy Howard wrote:
....

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

As jacob has demonstrated, your challenge is not sufficiently well
specified. He provided code which meets your specification, but only
very weakly supports the concept that there is a usable "nearly
conforming" C99 implementation. His code declares a VLA, but makes no
actual use of it, thereby very neatly side-stepping all the issues
related to the fact that the most commonly available compilers fail to
implement all VLA features correctly, and that different commonly
available compilers differ with regard to the ways in which they fail.
Only an idiot would think that such code proves that VLAs are well-
implemented by the compilers that can compile it, but the code does
meet your challenge.

The gcc "Status of C99" web page says:

Some details of variable length arrays (VLAs) relating to when size expressions are evaluated and when the
memory for VLAs is freed are not implemented, and other details are not checked against the requirements of
the C99 standard.

I can't tell from that description what precisely it is that gcc gets
wrong; and the second clause implies that gcc people themselves do not
know for sure, either. The second clause is the main reason I couldn't
use VLAs in any code that I was putting to serious use. For less
serious use, given the above description, I'd have to be very careful
about any use of sizeof, getjmp/longjmp, goto, or anything remotely
resembling Duff's Device in the vicinity of a gcc VLA. Except for
sizeof, that's not a serious restriction. However, I can easily
imagine wanting to pass "sizeof myvla" to a function like memcpy();
having to use "rows*cols*sizeof myvla[0][0]" rather than "sizeof
myvla" would be a pain, and a bit of a maintenance problem too.

I'm sure that someone who did know the exact nature of gcc's defective
handling of VLAs would be able to write a program that makes extensive
and sophisticated use of VLAs without ever triggering any of the
defects. Of course, the danger is that the next person who maintains
such code who knows less than the original designer about the nature
of gcc's defects could easily make a change that triggers one of them.
In the worst case, the resulting failures could easily be both silent
and too subtle to be easily noticed.

 

[Randy Howard]

Randy Howard wrote:
...

As jacob has demonstrated, your challenge is not sufficiently well
specified. He provided code which meets your specification,

Only for incredibly weak interpretations of "a reasonable selection
of new for C99 features". I didn't take his response seriously.

but only
very weakly supports the concept that there is a usable "nearly
conforming" C99 implementation. His code declares a VLA, but makes no
actual use of it, thereby very neatly side-stepping all the issues
related to the fact that the most commonly available compilers fail to
implement all VLA features correctly, and that different commonly
available compilers differ with regard to the ways in which they fail.
Exactly.

Only an idiot would think that such code proves that VLAs are well-
implemented by the compilers that can compile it

We are in total agreement on that point.

 

[s0suk3]

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.

You fail to understand that your considerations are not universal. But
whether 10 implementations are "many" or not isn't a very useful
subject. There are many implementations that have been ported to
several platforms, for example. So the interpretation of the term
"many" in this context depends heavily on how widely implemented those
implementations are. If, for example, all those 10 implementations
would be usable only in one platform, it would be irrelevant to
discuss whether 10 implementations are "many." What's relevant is how
the existence of those implementations directly affect portability.

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

Not if someone disagrees with you on what "many" is.

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.

What "other" evidence would that be?

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.

Perhaps, but in that case it's much of an irrelevant evidence
incapable of making a reasonable argument about this point.

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.

I haven't seen where they explicitly state that point, which is why I
said what I said. If it's true that they state that, then I take my
words back.

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

No, because most C new development in Windows doesn't constitute most
new C development in general.

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.

It would if the field you pointed out would constitute most actual new
C development.

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.

It is relevant, since you claimed that most new C development in
Windows was not done in C99 because MSVC is the most widely used C
compiler on Windows. My claim that MSVC isn't the only C compiler on
Windows is therefore relevant.

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.

Saying "your refutation is wrong" is not enough to demonstrate that it
is wrong. I'm afraid your opinion is irrelevant unless you make
arguments about why it is wrong.

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

The problem is actually that you talk about evidence without having
it. With this problem, it isn't even relevant whether people
understand what "evidence" means, since none is even presented.

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!

It depends on the case, of course, but what you claimed is that there
was some place where they mention that C99 support is broken, which
they don't.

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.

Yes, it is safe to assume that. Likewise, it is safe to assume that
your claim is wrong, since it is also wild and unsupported.

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.

No, but neither is it an evidence that GCC users don't have access to
some other compiler that is a C99 compiler.

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

As I already demonstrated, I did refute your point, which had no
support or evidence.

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!

Then those are probably not very competent C programmers, are they?

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.

But you don't know whether most people have heard of the book or of
C99. Whichever is the case, people who know only of one book about C
wouldn't be very good programmers anyway, so making an argument about
them wouldn't be very useful.

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.

Well, it might be used a lot in embedded programming, but it seems
unrealistic to believe that it is used more in embedded systems than
in actual OSs.

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.

It's only evidence (if it's true what you said) that shows that a
particular company uses C for embedded systems and not for non-
embedded programming. It's irrelevant as to what *most* C development
takes place on, which is what we were talking about.

No, you completely refuse to define it.

I have defined it many times in this thread.

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.

No, they're simply C90 + extensions compilers. (Though a C90 +
extensions compiler will probably also support C90 anyway.)

So
their use is evidence by your definition of what a Cxx compiler is that
C90 is used.

No, it isn't, and that sentence is completely unrelated to the rest of
your paragraph.

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.

Sure, you're arguing that, but you're not supporting your claims in
any reasonable way, which leads to believe against you.

In that case either:

1) gcc is *not* a C99 compiler so people using it are not using C99

I agreed that C90 + extensions development is not C99 development;
that has nothing to do with GCC being or not being a C99 compiler.

and
as people using gcc seems to be your main argument for the popularity of
C99 your position is completely untenable.

It is not my main argument for the popularity of C99, and you do not
present any arguments as to why GCC isn't a C99 implementation.

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.

The fact that GCC has a default mode of C90 + extensions shows no
evidence that people are using C90 + extensions, for two logical
reasons: (a) There are other compilers apart from GCC, and (b), people
don't always use the default mode.

However, both points are completely unrelated to what you quoted which
was my agreement that C90 + extensions development was not C99
development (which is only logical).

Most new posters to this group who use gcc use it in its default mode as
shown by their posts.

Those new posters are usually beginners. I don't think they would
constitute the majority of C programmers, let alone the most relevant
ones.

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.

Not by people who are concerned with portability, since working in
that mode would limit the code to be compiled only under GCC.

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.

You said that by my definition most C90 + extensions compilers are C90
compilers. Regardless of whether that's true, it has nothing to do
with development being in C90 or in C99.

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

The fact that it's the mode most compilers default to does not mean
that it's the mode most people use.

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

Actually, you have no evidence.

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.

Neither one of those points are true, and if we are disagreeing on
what an "evidence" means, it's you the one who doesn't understand the
term. Let's see what the dictionary has to say about it:

1. that which tends to prove or disprove something; ground for belief;
proof.
2. something that makes plain or clear; an indication or sign.

You have not presented anything like that so far, and yet you continue
to claim so.

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

Exactly.



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

I'm afraid a single word does not demonstrate much. For example, I
could also claim they conform to C99 by saying that the page
explicitly mentions "conforming" (look around line five), but they do
not actually claim to conform. It's called "taking a word out of
context."

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

Yes, that's what I've seen so far.

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

No. I agreed that a broken compiler should be ruled out as being a

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

Well, sure, to /you/.

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.

As I demonstrated, it's you the one who doesn't understand that (look
at the dictionary definitions again).

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

Non sequitur. I said that what I mentioned *wasn't* an evidence (which
is also what you claimed), and then you respond by saying that I don't
know what "evidence" is.

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

As I demonstrated, you are the on who doesn't know what evidence
means.

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

No. The reason for specifying which compiler to use can be anything.
Here are some clues:

o Compiler X is cheaper than compiler Y
o Compiler X is better than compiler Y
o Management likes compiler X better than compiler Y
o Management simply picks whatever compiler is at hand

Compiler Y not being available would be just another possible such
reason.

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

As demonstrated above, management specifying some particular compiler
does not mean that anything else isn't available.

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.

How can awareness of a free C90 implementation be irrelevant if
they're looking for a free C90 implementation? Try to make conclusions
that follow the premises; that way you might be able to speak
logically.

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.

Yes, but you did not talk about choosing a random compiler and using
what it supports; you talked about being aware of free
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.

Well, since now you're talking about randomly selected compilers: that
randomly selected compiler might not even be a free C90/C99
implementation!

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

By that token, it relates to whether they are using _any_ compiler,
regardless of what standard.

No, it is relevant to the specific point you made.

But you admitted that it was irrelevant:

"It was an aside and nothing to do with the main point of this
thread."

A point about which
you were wrong.

You said I was wrong and then made a completely unrelated comment (by
your own admission). That does not demonstrate that I was wrong.

You are wrong to think that a C99 implementation is
likely to be of lower quality than a C90 implementation.

I don't think that, and have never claimed anything like that.

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.

Yes, and even though I haven't claimed that, it is a strong argument
as to why a C99 compiler might be of higher quality than a C90
compiler.

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

It only shows that you made a claim of falsehood followed by a
completely unrelated comment.

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

Neither have you.

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

I demonstrated above that, according to the dictionary, I do
understand it, unlike you.

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

Is talking about your C development career what you consider "eye-
witness evidence"?

Buy some new glasses.

What you said had nothing to do with what was being discussed.

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.

Yes, but, the question remains: what does that have to do with the
text you quoted, which was about the three points mentioned by Richard
and my claim that those apply to an implementation of any standard?

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.

You should keep in line with the points being discussed, since not
doing so only creates misunderstandings.

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

No, what I'm doing is interpreting your points that are supposedly in
relation to the text you quote above. But that's hard to do since you
don't actually follow the points of the discussion.

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's great that you summarize what you meant; that way you might
actually see it now: That has nothing to do with the three points
being discussed and why they are or aren't applicable to an
implementation of any standard.

Anyway, your current point is unrealistic, since people don't actually
choose their compilers by throwing a bunch into a bag and randomly
selecting one.

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.

My claims were not about why one might not end up with a C99 compiler
as less likely to apply to C90 (whatever that means). My claims were
about why the points being discussed would be applicable to an
implementation of any standard.

I still have not said you made that claim.

Yes, you did:

"Those to claims amount to a claim that you believe that Richard's
work is not used in embedded systems"

Don't say stuff if you're later going to deny you said it.

It is the logical conclusion.

Then this is evidence that your logic does not lead to reality, since
I never made that claim.

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.

Not necessarily. At the time I said that they would most likely find
C99 acceptable I wasn't considering what kinds of systems they were
using; I was just thinking in general, and in general, my claim was
true.

However, how you misinterpret my posts by assuming implicit claims is
not my problem.

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.

Richard told me enough in order to make that conclusion when he said
that they don't tell him about their systems, and that they just
assume that whatever he sends them will work on their systems. I then
said that he could send code of any kind and that it would be fine if
they didn't object, to which he agreed. Based on this, Richard's
claims about them not being able to accept C99 was an assumption made
only out of his opinions on C99 availability, which might well be
wrong.

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.

No, they don't explicitly state that, and you have not provided any
quote out of their website where they explicitly mention this (other
than the word "broken", which I demonstrated was taken out of
context).

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

Exactly.

Sebastian

 

[s0suk3]

(e-mail address removed) said:



Right, which is why I supplied evidence to support my view. Not for my
benefit, but for other people's.

You didn't *supply* evidence; you *mentioned* the evidence, which is,
unfortunately, not sufficiently convincing to make a strong and
reasonable argument.

Yes, I know you do, and it's quite clear that no amount of evidence is
going to change your mind. I can live with that.

No only me. And perhaps no amount of mentioned evidence will do that,
but maybe some clearly presented evidence would.

Yes, I know - but *I'm* sure who I mean.


Simple - it's because they have demonstrated this on countless occasions.


No, it's because they can't read with any degree of comprehension.

Well, that's not much of an answer. The one you gave above, "because
they have demonstrated this on countless occasions" *is* a valid and
reasonable answer, but I don't know who "they" are, nor do I know when
they have demonstrated that, so I can't comment on whether it's true
or not.

It is clear from your reply that you still don't understand the nature of
eye-witness evidence, even though it has been explained to you several
times.

It sure has been explained, but regardless of who understands it, no
such evidence has been presented.

The current de facto standard, yes. Not the de jure standard, since there
aren't sufficiently many C99 installations to make that feasible -
*unless* the portability is only required across C99 installations, in
which case it's obviously just fine to rely on C99 features.

I think it's clear that we don't agree on what the current standard
means, even though the dictionary disagrees with you, but hey, you've
got your own terminology...

You have not demonstrated this, and I don't believe it to be true. Can you
convince me by providing evidence? 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", for reasons that have already been
explained ad nauseam).

It depends on what you mean by "C99 installation" (is that term in the
standard?). There's for example GCC, Intel, Sun, lcc-win, etc. Though
I don't have the intention of giving an exhaustive list; anyone can
find that out on his own.

Reported observations [of C99 installations in the field]? If you're
talking about /your/ reported observations, remember that not everyone
of us can see through your mind.
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.

They have been, in this case. I reported them. Let me do so again. 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.

Do you mean "installation" as in "a compiler installed on an actual
machine"? If yes, then that report is surely valid--it simply shows
that you work on systems where there haven't been C99 installations
(which sounds a little unrealistic since some OSs actually come with
one pre-installed). But reports like this are hardly useful; anyone
could come and say the same thing about installations of a compiler
for any standard!

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

With the definition of "installation" as described above, yes: Intel.
But again, that's hardly a useful comment.

My knowledge about you is based purely on what you write here, and it is on
that basis that I draw the conclusion that you don't understand what
you're observing.

Then your knowledge about me is mistaken.

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>

Right. That makes it... TWO people!

Also note that he mentioned that the term wasn't very useful _in the
context_ that he specified.

In this very thread, people have presented research that backs this up.
Here's an example, and it's James Kuyper again: "A quick Google Groups
search gives an estimated 880 uses of "C99 implementation" across all
newsgroups. Among the first 100 hits, the only ones that I could find
using that term to refer to an implementation which falls short of being
fully conforming are by you and jacob navia. A large fraction of those
hits involve arguments about that very issue, in this newsgroup."

Message ID:
<[email protected]>

The very first sentence is wrong. A Google Groups search across all
newsgroups gives an estimated 17,600 uses of "C99 installation." And I
did find people other than me and Jacob Navia who used the term as he
described:

http://groups.google.com/groups/search?qt_s=1&q=C99+implementation

Not to the Flat Earth Society. (Their home page appears to be
http://www.alaska.net/~clund/e_djublonskopf/Flatearthsociety.htm although
I can't guarantee this.)

Well, it was your comment

It is to most of us. Your views seem as odd to me and to others here

But not to everybody.

as
those of a Flat Earther would seem to you.

Err... to us!

No, it wouldn't take any lawyer work. The claim has already been backed up,
by other people here, none of whom is a corrupted lawyer (or indeed a
lawyer of any kind) as far as I am aware. Now, the backing up of such a
claim with evidence does not of itself make it *true* - it simply makes
the claim more likely to be true. If you wish to attack the claim, fine,
but to convince people that you're right you will need to do more than
simply claim "it's false". You need to demonstrate why it's false. If you
can *prove* it's false, fine - do it. But if not, you should at least be
able to provide plausible *evidence* that it's false, and you have not yet
done this.

True, because I believe it to be hardly possible to prove (and so too
for the opposite). And little "evidences" that simply make the claim a
little bit more likely to be true are nearly useless and don't achieve
anything in the end.

Neither did I claim that they all do. For one thing, there are at least
three people, possibly four, in this very group who are prepared to
disagree with just about any claim I make, no matter how unexceptionable
it might be.

You talk as if those people who disagree with you would just do it out
of stubbornness. But even if those three or four people do, I'm
certain they're not the only ones that would disagree with what you
said.

Nevertheless, the research presented in this thread - not by
me, but by others participating in this discussion - does suggest very
strongly that I'm right.

Well, at least the research you mentioned by James Kuyper was
mistaken, as I explained above.

Sebastian

 

[jameskuyper]

Only for incredibly weak interpretations of "a reasonable selection
of new for C99 features". I didn't take his response seriously.

My point is that your specification allows that weak of an
interpretation. Until you make it more specific, he's going to have no
trouble "meeting" your specification.

 

[s0suk3]

(e-mail address removed) said:



You still don't understand what evidence is.

You snipped a relevant part. The rest continued as: "you *mentioned*
the evidence, which is, unfortunately, not sufficiently convincing to
make a strong and reasonable argument."

I am sure I've explained this several times already. Still, here we go
again. I mean a copy of a conforming C99 implementation that has actually
been installed on a particular machine. If "conforming C99 implementation"
were a type, it would be an object of that type.


No - it's a term I concocted to describe the concept of a C99
implementation that a particular programmer is actually using, to make it
easier to talk about the very important fact that, simply because (say)
EDG has a conforming C99 implementation, that doesn't mean that everybody
in the world has access to a C99 implementation. The proportion of C99
implementations to C90 implementations gives you a guide to how seriously
implementors take C99 (i.e. not very), but the proportion of C99
*installations* to C90 installations tells you how seriously *programmers*
take C99 (i.e. not even remotely).

Well, you have talked about /your/ observations of C99 installations.
And that's perfect. But not everybody has the same observations as
you, so you can't say the same thing about all C programmers by basing
on those observations.

Neither gcc nor lcc-win are conforming C99 implementations, and therefore
any installation of gcc or lcc-win is not a C99 installation.

Well, you hadn't specified that you meant a conforming C99
implementation.

You failed to provide even an *accurate* list, let alone an exhaustive one
- half the entries on it were wrong.

Only because I'm not familiar with your private terminology, and
therefore can't speak fluently using it.

****** APPLAUSE!!! ******


Could it be that you are beginning to understand what eye-witness evidence
is?

It's probably that I'm finally getting to understand your very
intimate terminology!

My claim is broader than that. I'm saying that in all the time I've been
using C, I have never once seen a single copy of a C99 compiler installed
on *any* machine on *any* site where I've worked - and I've been around
the block a few times, I assure you. I don't just mean the machines I've
used - I mean all the other machines in the place too. No C99 - zip, nada,
nil, ne C99 pas. Not a single installation. Not even a little one.

How is that different from the conclusion I made? It's simply that:
you haven't seen any. That raises some rather interesting questions
about the places where you've worked...

Name two. In fact, name one. (Note that gcc is not a C99 implementation, so
Linux certainly doesn't count.)

It is a C99 implementation, so it counts (and not only Linux, but
other UNIX variants like Mac OS X and Solaris).

I disagree.


Anyone who has never seen a C90 installation clearly has no C experience
worth speaking of, since C90 implementations are widespread and have been
for almost twenty years. But C99 installations are another matter. I've
never seen one, and neither has Randy Howard (another very experienced C
programmer). Nobody who has taken part in this discussion, as far as I'm
aware, has ever seen one. Actually, that rather surprises me. I would have
guessed that at least one regular comp.lang.c contributor might have seen
/one/ C99 installation. But nobody has so far come forward to say so. The
evidence on your side is so sparse that it is currently non-existent.

Anyone who has worked on a UNIX variant has been in front of a C99
installation (unless, of course, we're talking about /your/ definition
for "C99 installation").

On the contrary, it's revelatory. You have actually claimed, for the very
first time, to have witnessed the existence of an actual C99
implementation installed on an actual machine. Now, I won't be so churlish
as to disbelieve you - I will accept the veracity of the eye-witness
evidence that you have just provided - but I invite you to compare this
figure of... ONE... with the number of C90 installations you've seen.

I've seen only two C90 installations. See? Not a very useful comment.

If you have only ever seen ONE C90 installation, then your experience of C
is certainly insufficient to justify the claims you are making about it.

No. The experience of someone as a C programmer isn't based on the
number of C installations that that person has seen. For example, a
person who has never been introduced to C might see 10 C installations
in one day, while another person might have been working with C using
only one installation during several years.

And if you have seen more than one, then it would seem that even you must
realise that the number of C90 installations outnumbers the number of C99
installations, and consequently it can hardly be "usual" for new C
developments to be undertaken using C99.

The fact that there are more installations of C90 doesn't mean that
most new C development is done in C90. I, for example, and according
to your definition of "installation," have seen the double of C90
installations than C99 installations (i.e., 2 vs. 1), and yet most new
C development I've started has been in C99. Of course, this is just a
minimal example, but it shows that the fact that there are more
installations of compilers for a particular standard doesn't imply
that most new development takes place using that standard.

In which case the inescapable conclusion is that what you write here is
also mistaken, because it is on that writing that my knowledge of you is
based.

Which only means that you have misinterpreted the statements in that
writing.

You said I was the only one. I produced a counter-example that proves you
wrong. Keith Thompson is another (see his reply, parallel to yours, in
which he points this out).

Sure, you proved me wrong and now we've got... would you believe it,
THREE people!!

And bear in mind that others who may otherwise
have objected refrained from doing so because they had seen that James and
Keith had already voiced that view (this is good Usenet practice).

We could say the same about the opinion I and Jacob Navia have.

No, you just misread it - understandably, in this case. The quotation marks
around "C99 implementation" are significant.


Searching for:
C99 implementation
in Google Groups, I get 17,600 hits, as you say.

Searching for:
"C99 implementation"
in Google Groups, I get 958 hits. Clearly we've used the term a number of
times since James did his research.

I see... but why in heaven's sake would someone search for something
using quotation marks?

I'm not about to plough through 17600 hits looking for one that backs you
up.

Neither am I :-(

If such an article exists, please provide a reference to it.




If you can't show that it's false or at least defend the claim that it's
false, you have no business saying it's false. Doing so just makes you a
laughing-stock.

By that token, we're both a laughing-stock, since neither of us has
been able to fully prove our claims.

Yes. Now, a great many people disagree with me when I'm wrong or at least
not obviously right - Keith Thompson, Chris Torek, David Thompson, the
lower-case santosh, Martin Ambuhl, Dann Corbit, Ben Pfaff, James Kuyper,
Larry Jones, and plenty more besides. But there are some people who
disagree with me not because I'm wrong (or not obviously right) but
because they're either stupid or malicious or both (and "both" seems the
most likely). It's a small handful of people, but quite a noisy bunch.

But like I said, I'm certain that in this case they're not just that
noisy bunch the ones who disagree with you.

No, it wasn't mistaken at all. You simply misinterpreted it.

"Well," "I'm" "not" "used" "to" "live" "in" "a" "world" "where"
"people" "make" "their" "searches" "with" "quotation" "marks" "around"
"the" "words"!

Sebastian

 

[Keith Thompson]

Only because I'm not familiar with your private terminology, and
therefore can't speak fluently using it.

How many times do we have to explain to you that most of us use the
term "C99 implementation" to refer to a *fully conforming*
implementation of the C99 language?

Seriously, how many times? Give us a number.

[...]

It's probably that I'm finally getting to understand your very
intimate terminology!

Well, that's a relief ...

[...]

It is a C99 implementation, so it counts (and not only Linux, but
other UNIX variants like Mac OS X and Solaris).

.... or maybe not.

gcc is not a C99 implementation. gcc is a *partial* C99
implementation.

[...]

Anyone who has worked on a UNIX variant has been in front of a C99
installation (unless, of course, we're talking about /your/ definition
for "C99 installation").

Anyone who has ever been to a horse farm has been in front of a
unicorn (unless, of course, we're talking about /your/ definition for
"unicorn").

[...]

I've seen only two C90 installations. See? Not a very useful comment.

Only two? Seriously? There are at least two in the room I'm sitting
in (and it's not a big room).

[...]

I see... but why in heaven's sake would someone search for something
using quotation marks?

Um, because they're significant in Google searches. Searching for
"C99 implementation" with quotation marks finds pages containing the
phrase "C99 implementation"; without the quotation marks, it finds
pages containing the word "C99" and the word "implementation".

[...]

 

[s0suk3]

How many times do we have to explain to you that most of us use the
term "C99 implementation" to refer to a *fully conforming*
implementation of the C99 language?

Like I've said, I don't think that "most" of us use the term that way
(not always, of course), and none of us has been able to prove for or
against it. Getting to know the ng, I realize that most people here do
use the term that way. So if by "most" you mean the people here, then
you're probably right.

Seriously, how many times? Give us a number.

None, since it's not a matter of understanding.

Well, that's a relief ...

For Richard, sure...

[...]

It is a C99 implementation, so it counts (and not only Linux, but
other UNIX variants like Mac OS X and Solaris).

... or maybe not.

gcc is not a C99 implementation. gcc is a *partial* C99
implementation.

That's a way to see it. Some people would sometimes refer to GCC as a
C99 implementation only for brevity. Some others would refer to it as
a C99 implementation because it has implemented it and has only minor
failures.

[...]

Anyone who has worked on a UNIX variant has been in front of a C99
installation (unless, of course, we're talking about /your/ definition
for "C99 installation").

Anyone who has ever been to a horse farm has been in front of a
unicorn (unless, of course, we're talking about /your/ definition for
"unicorn").

What guarantees that a horse farm has a unicorn?

Um, because they're significant in Google searches. Searching for
"C99 implementation" with quotation marks finds pages containing the
phrase "C99 implementation"; without the quotation marks, it finds
pages containing the word "C99" and the word "implementation".

With quotation marks, does it find the phrase "C99 implementation"
*including* the quotation marks (i.e., the " characters at the start
and end of the words)? Or does it simply find the phrase "C99
implementation" excluding the quotation marks?

Sebastian

 

[James Kuyper]

You didn't *supply* evidence; you *mentioned* the evidence, which is,
unfortunately, not sufficiently convincing to make a strong and
reasonable argument.

It seems to me that he did supply the evidence. Perhaps if you gave an
example of the difference you see between "supplying" and "mentioning"
evidence, he could find a way say exactly the same thing he's already
said in terms that would allow you to recognize it as "supplying" evidence.

....

Also note that he mentioned that the term wasn't very useful _in the
context_ that he specified.

I don't think it's useful in general, either, but I thought it might be
easier for you to accept my statement as true if I restricted it's
applicability.

....

The very first sentence is wrong. A Google Groups search across all
newsgroups gives an estimated 17,600 uses of "C99 installation."

The term I was discussing was "C99 implementation", not "C99
installation". You'll find lots of computer people using the second
term; the first term is likely to be used mainly by people interested in
and knowledgeable of the C standard.

 

[James Kuyper]

It is a C99 implementation, so it counts (and not only Linux, but
other UNIX variants like Mac OS X and Solaris).

It does not fully conform to the C99 standard, which is the only sense
in which I or Richard Heathfield or many other people in this newsgroup
use the term "C99 implementation". I will graciously acknowledge that it
matches your misuse of the term to refer to nearly-conforming
implementations, but such implementations are not relevant to Richard
Heathfields comments.

....

Anyone who has worked on a UNIX variant has been in front of a C99
installation (unless, of course, we're talking about /your/ definition
for "C99 installation").

I've worked on many Unix variants that didn't even have what you would
call a C99 installation, much less a compiler that actually qualifies a
a C99 installation. Possibly you think that C99 is older than it really
is? Or possibly that Unix is younger than it really is?

....

I see... but why in heaven's sake would someone search for something
using quotation marks?

Because a search for "C99 implementation" retrieves only those messages
which contain the phrase "C99 implementation", which is what we were
discussing. Without the quotation marks, it retrieves any message that
contains both the word "C99" and the word "implementation", even if
those words are nowhere near each other. Why would you do the search
without the quotation marks? Don't you know anything about how to use
search engines? This is a common feature on a wide variety of them.

....

"Well," "I'm" "not" "used" "to" "live" "in" "a" "world" "where"
"people" "make" "their" "searches" "with" "quotation" "marks" "around"
"the" "words"!

You need to learn more about the features of typical search engines.

 

[Keith Thompson]

That's a way to see it. Some people would sometimes refer to GCC as a
C99 implementation only for brevity. Some others would refer to it as
a C99 implementation because it has implemented it and has only minor
failures.

The vast majority of participants in this newsgroup use the term "C99
implementation" only to refer to fully conforming C99 implementations.
Your refusal to admit that any usage other than your own is valid is,
I think, a large part of what's led to this tedious discussion.

[...]

What guarantees that a horse farm has a unicorn?

If you define a "C99 implementation" as something that implements most
of C99, without further specifying that it must implement all of C99,
C99 implementations are easy to find.

If you define a "unicorn" as a horse-like animal, without further
specifying that it has a long horn on its forehead, unicorns are easy
to find.

In both cases, I find the hypothetical definitions misleading because
they leave out important factors.

With quotation marks, does it find the phrase "C99 implementation"
*including* the quotation marks (i.e., the " characters at the start
and end of the words)? Or does it simply find the phrase "C99
implementation" excluding the quotation marks?

Since this isn't an appropriate forum for
discssing how to use Google, I'll just refer you to
<http://www.googleguide.com/quoted_phrases.html>. (In the future,
you might consider not ridiculing things you don't understand.)

 

[Kenny McCormack]

The vast majority of participants in this newsgroup use the term "C99
implementation" only to refer to fully conforming C99 implementations.

Where the term "vast majority" means about 10 (out of hundreds of total
participants). These 10 are the so-called "regs" - and it is they who
do most of the posting.

No sane person defines things the way that Keith does - but the regs
certainly do.

 

[Flash Gordon]

You fail to understand that your considerations are not universal. But
whether 10 implementations are "many" or not isn't a very useful
subject.

If we don't have any clue about what you mean by "many" then your
statement is worthless. My experience suggests that there are not "many"
C99 implementations.

There are many implementations that have been ported to
several platforms, for example. So the interpretation of the term
"many" in this context depends heavily on how widely implemented those
implementations are. If, for example, all those 10 implementations
would be usable only in one platform, it would be irrelevant to
discuss whether 10 implementations are "many." What's relevant is how
the existence of those implementations directly affect portability.

So how many of those implementations will build the following C99
program and execute it correctly:

#include <stdio.h>
#include <math.h>

int main(void)
{
printf("%f\n",atan2(1,1));
}

The nearest thing I have to a C99 implementation certainly does not.

To save you some trouble I'll let you know that it does not build on Linux.

Not if someone disagrees with you on what "many" is.

So what did you mean by "many" above? 1% of installed C implementations,
1% of available C99 implementations or what?

What "other" evidence would that be?

The evidence presented by James for a start.

Perhaps, but in that case it's much of an irrelevant evidence
incapable of making a reasonable argument about this point.

In that case all of the evidence for all current scientific theories is
completely irrelevant because the decent scientist who obtain it know it
does not actually prove anything just suggests that the theories are
correct.

I haven't seen where they explicitly state that point, which is why I
said what I said. If it's true that they state that, then I take my
words back.

Quote from the gcc info pages, "gnu89 GNU dialect of ISO C90..."
Quote from the gcc info pages, "c99... ISO C99. Note that this standard
is not yet fully supported...", so they explicitly state it is not full
support.
Quote from the gcc info pages, "gnu99... GNU dialect of ISO C99. When
C99 is fully implemented in GCC, this will become the default."

There you are, quotes supporting what gnu89 is, what gnu99 is, and the
reason that gnu99 is not the default.

They also say that various bits of it are broken as you well know, and
how can something be considered not-broken if part of it is broken?

Then there is the simple program above which is C99 and fails to build
under gcc on Linux. How can it not be broken if a simple C99 fails to build?

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

No, because most C new development in Windows doesn't constitute most
new C development in general.

It is a large area of the field. Another large area is embedded
development. So that is two large areas where C99 is definitely by far
in the minority.

It would if the field you pointed out would constitute most actual new
C development.

It is a large sample. Add to that another large area, namely GNU, where
the GNU coding standards state:
"1989 Standard C is widespread enough now that it is ok to use its
features in new programs."

"1999 Standard C is not widespread yet, so please do not require its
features in programs."

Then there is embedded SW development.

It is relevant, since you claimed that most new C development in
Windows was not done in C99 because MSVC is the most widely used C
compiler on Windows. My claim that MSVC isn't the only C compiler on
Windows is therefore relevant.

We were talking about what C development is actually done in. The
availability of compilers which are not much used does not affect this.

Saying "your refutation is wrong" is not enough to demonstrate that it
is wrong. I'm afraid your opinion is irrelevant unless you make
arguments about why it is wrong.

You are using the presence of C99 compilers for Windows as evidence that
most development is done in C99. As you have admitted that most Windows
development is done in a compiler that does NOT support C99 that part of
your refutation is clearly wrong. Other parts have been addressed
else-where in this thread.

The problem is actually that you talk about evidence without having
it. With this problem, it isn't even relevant whether people
understand what "evidence" means, since none is even presented.

Your failure to understand the term is relevant because it has presented
you from recognising that some has been presented.

It depends on the case, of course, but what you claimed is that there
was some place where they mention that C99 support is broken, which
they don't.

If the handle of a mug is broken then the mug is broken. The status page
states parts of gcc are broken with respect to C99 so gcc is broken with
respect to C99. You have seen the page which states that parts are
broken, and it even uses that specific word.

Yes, it is safe to assume that. Likewise, it is safe to assume that
your claim is wrong, since it is also wild and unsupported.

So says the person who knows what C implementations are used on the
bases of a massive sample of three?

Anyway, it is rather hard to escape knowledge of K&R as a C programmer.
Do a google search for "C Programming Language" without the quotes and
you hit it.

Some compilers come with a copy of the 2nd edition.

Ask in most places for recommendations of books and someone is likely to
point in that direction.

Ask any old-time C programmer (and new programmers do ask old-time
programmers) and the chances are you will be pointed in that direction.

Eye-witness evidence, I've met far more people who have heard of
Kernighan and Ritchie than have heard of the C standard.

Then those are probably not very competent C programmers, are they?

I don't see a correlation because most of the good developers I have
come across outside this group had not heard of C99.

But you don't know whether most people have heard of the book or of
C99.

Experience suggests that more people have heard of K&R than have heard
of C99.

Whichever is the case, people who know only of one book about C
wouldn't be very good programmers anyway, so making an argument about
them wouldn't be very useful.

Where did I say that K&R was the *only* book they know?

Well, it might be used a lot in embedded programming, but it seems
unrealistic to believe that it is used more in embedded systems than
in actual OSs.

Well, let me count the pieces of kit in this house with embedded SW...
Well, I can think of 20 pieces of kit in this house that definitely have
embedded SW, a lot of those pieces of kit (for example this PC) have
more than one processor and more than one piece of embedded SW (graphics
card has a processor and embedded SW, so does the sound card, the HW,
the DVD drive...).

It's only evidence (if it's true what you said) that shows that a
particular company uses C for embedded systems and not for non-
embedded programming. It's irrelevant as to what *most* C development
takes place on, which is what we were talking about.

It covers a wider range than your experience (I used more than three
different C implementations there) so is more relevant than your
experience. Remember that you have used your experience in argument with
Richard.

I have defined it many times in this thread.

The nearest you have come to defining it is saying that something which
does not conform to C99 is a C99 implementation.

No, they're simply C90 + extensions compilers. (Though a C90 +
extensions compiler will probably also support C90 anyway.)

I've yet to find one that cannot be made to fully conform. I've yet to
find one that with all extensions enabled is not closer to fully
conforming the gcc ever comes to conforming to C99.

No, it isn't, and that sentence is completely unrelated to the rest of
your paragraph.

So you claim that something vaguely close to conforming to C99 is a C99
implementation but something very close to conforming to C90 (which with
a simple switch becomes fully conforming) is not a C90 implementation?

If gcc in *any* mode counts as being a C99 implementation by your rules,
then all implementations in their C90+extensions modes are C90
implementations.

If C90+extensions compilers don't count as C90 implementations (unless
full C90 conformance is enabled) then gcc can't be a C99 implementation
as it is even further away from conformance. Also remember that a lot of
extensions don't affect conformance.

Sure, you're arguing that, but you're not supporting your claims in
any reasonable way, which leads to believe against you.

See above.

I agreed that C90 + extensions development is not C99 development;
that has nothing to do with GCC being or not being a C99 compiler.

It means that all those people using C90+extensions are not using C99.

It is not my main argument for the popularity of C99, and you do not
present any arguments as to why GCC isn't a C99 implementation.

The only other argumens you have given are that:
C99 is the current standard.
Your personal experience.

You have shown that your personal experience is limited (you have only
come across 3 implementations) and C99 being the current standard proves
nothing about how much it is used.

The fact that GCC has a default mode of C90 + extensions shows no
evidence that people are using C90 + extensions, for two logical
reasons: (a) There are other compilers apart from GCC, and

Most of the rest of the compilers around are not C99 compilers.

(b), people
don't always use the default mode.

No, but it is the most common mode.

However, both points are completely unrelated to what you quoted which
was my agreement that C90 + extensions development was not C99
development (which is only logical).

Which was part of a larger argument.

Those new posters are usually beginners. I don't think they would
constitute the majority of C programmers, let alone the most relevant
ones.

Well, the experienced people here recommend using the -ansi -pedentic
switches which put it in to fully C90 conforming mode. So we now have a
sample from beginner to experienced almost all using C90 or C90+extensions.

Not by people who are concerned with portability, since working in
that mode would limit the code to be compiled only under GCC.

I was not talking about people who care about portability since, for
reasons already explained, the majority of them will *not* use C99
because most compilers do not conform to the C99 standard.

You said that by my definition most C90 + extensions compilers are C90
compilers. Regardless of whether that's true, it has nothing to do
with development being in C90 or in C99.

It does when you remember the other bits earlier in the post about why
most people use C90+extensions.

The fact that it's the mode most compilers default to does not mean
that it's the mode most people use.

Experience suggests that most people do nothing to enable compliance to
any standard. Of those who do enable conformance to a standard
experience suggests that most people select C90.

Exactly.

You have been told a lot of things which are indicative and give an
outward sign, some of which you could verify independently. You have
been told a lot of things that would be helpful to most people in
forming a conclusion or judgement.

I'm afraid a single word does not demonstrate much. For example, I
could also claim they conform to C99 by saying that the page
explicitly mentions "conforming" (look around line five), but they do
not actually claim to conform. It's called "taking a word out of
context."

A more complete quote which you have already been given is, "variable
length arrays broken". This being an extract from a table of
features. If the handle of a mug is broken then the mug is broken.

Yes, that's what I've seen so far.

Well, that shows you that there are far more C90 implementations than
C99 implementations. Therefore C90 is far more portable than C99.
Therefore people who really care about portability will have to stick to
C90.

No. I agreed that a broken compiler should be ruled out as being a
<whatever> implementation. That has nothing to do with GCC being or
not being a C99 implementation.

It does. I've now even provided some very simple code that demonstrates
that it is broken.

Well, sure, to /you/.

OK, so you need a hearing aid as well as new glasses.

No. The reason for specifying which compiler to use can be anything.
Here are some clues:

o Compiler X is cheaper than compiler Y
o Compiler X is better than compiler Y
o Management likes compiler X better than compiler Y
o Management simply picks whatever compiler is at hand

Compiler Y not being available would be just another possible such
reason.

All of which are more likely to lead you to having a C90 implementation
that a C99 implementation.

As demonstrated above, management specifying some particular compiler
does not mean that anything else isn't available.

It means that nothing else is available to those developers. That is
what management specifying something means.

How can awareness of a free C90 implementation be irrelevant if
they're looking for a free C90 implementation? Try to make conclusions
that follow the premises; that way you might be able to speak
logically.

I explicitly did NOT say they were looking for a C90 compiler. The
ENTIRE POINT is that you DON'T need to be aware of ANY version of the C
standard to end up with a C90 implementation. Therefore most people WILL
end up with a C90 implementation.

Yes, but you did not talk about choosing a random compiler and using
what it supports; you talked about being aware of free
implementations.

I talked about choosing a compiler for reasons other than wanting
conformance to a particular version of the standard. Unless you can show
some statistical correlation between conformance to versions of the
standard and another desirable attribute then it is effectively random
which standard will be supported with a distribution very skewed towards
C90 implementations due to simple numbers.

Well, since now you're talking about randomly selected compilers: that
randomly selected compiler might not even be a free C90/C99
implementation!

I've already explained the odds.

By that token, it relates to whether they are using _any_ compiler,
regardless of what standard.

Stop talking rubbish. You don't need to be aware of standards *or* free
compilers to use a compiler. You just need a compiler, and the odds are
it will be a C90 compiler.

Yes, you did:

"Those to claims amount to a claim that you believe that Richard's
work is not used in embedded systems" ^^^

Don't say stuff if you're later going to deny you said it.

You keep saying you never claimed that Richard's work IS for embedded
systems. I have never said you claimed Richard's work IS for embedded
systems. I have pointed out that you assumed the OPPOSITE, that
Richard's work is NOT for embedded systems. You just quoted both those
things above.

Not necessarily. At the time I said that they would most likely find
C99 acceptable I wasn't considering what kinds of systems they were
using; I was just thinking in general, and in general, my claim was
true.

What Richard's customers use his code for is entirely relevant to what
will be acceptable.

However, how you misinterpret my posts by assuming implicit claims is
not my problem.

I was pointing out that you are assuming things about his customer base
and that you can only make claims about C99 being acceptable by making
those assumptions.

Richard told me enough in order to make that conclusion when he said
that they don't tell him about their systems, and that they just
assume that whatever he sends them will work on their systems. I then
said that he could send code of any kind and that it would be fine if
they didn't object, to which he agreed. Based on this, Richard's
claims about them not being able to accept C99 was an assumption made
only out of his opinions on C99 availability, which might well be
wrong.

your assumptions are wrong.If Richard has 10 customers and one of them
wants his code for embedded systems then your assumptions are wrong. If
one of his customers insists on using Microsoft Visual Studio (not
uncommon for Windows development) then your assumptions are wrong. If
Richard's code is doing Maths and he uses the C99 atan2 function and his
customers are using gcc on Linux then You assumed a *lot* about his
customers when you claimed that C99 was acceptable.

<snip>

Since you are basing your argument on very limited experience and refuse
to accept anything contrary to your preconceived notions I don't see the
point in continuing this. I've snipped a lot of the rubbish you were
talking. Feel free to have the last word.

 

[Flash Gordon]

You fail to understand that your considerations are not universal. But
whether 10 implementations are "many" or not isn't a very useful
subject.

If we don't have any clue about what you mean by "many" then your
statement is worthless. My experience suggests that there are not "many"
C99 implementations.

There are many implementations that have been ported to
several platforms, for example. So the interpretation of the term
"many" in this context depends heavily on how widely implemented those
implementations are. If, for example, all those 10 implementations
would be usable only in one platform, it would be irrelevant to
discuss whether 10 implementations are "many." What's relevant is how
the existence of those implementations directly affect portability.

So how many of those implementations will build the following C99
program and execute it correctly:

#include <stdio.h>
#include <math.h>

int main(void)
{
printf("%f\n",atan2(1,1));
}

The nearest thing I have to a C99 implementation certainly does not.

To save you some trouble I'll let you know that it does not build on Linux.

Not if someone disagrees with you on what "many" is.

So what did you mean by "many" above? 1% of installed C implementations,
1% of available C99 implementations or what?

What "other" evidence would that be?

The evidence presented by James for a start.

Perhaps, but in that case it's much of an irrelevant evidence
incapable of making a reasonable argument about this point.

In that case all of the evidence for all current scientific theories is
completely irrelevant because the decent scientist who obtain it know it
does not actually prove anything just suggests that the theories are
correct.

I haven't seen where they explicitly state that point, which is why I
said what I said. If it's true that they state that, then I take my
words back.

Quote from the gcc info pages, "gnu89 GNU dialect of ISO C90..."
Quote from the gcc info pages, "c99... ISO C99. Note that this standard
is not yet fully supported...", so they explicitly state it is not full
support.
Quote from the gcc info pages, "gnu99... GNU dialect of ISO C99. When
C99 is fully implemented in GCC, this will become the default."

There you are, quotes supporting what gnu89 is, what gnu99 is, and the
reason that gnu99 is not the default.

They also say that various bits of it are broken as you well know, and
how can something be considered not-broken if part of it is broken?

Then there is the simple program above which is C99 and fails to build
under gcc on Linux. How can it not be broken if a simple C99 fails to build?

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

No, because most C new development in Windows doesn't constitute most
new C development in general.

It is a large area of the field. Another large area is embedded
development. So that is two large areas where C99 is definitely by far
in the minority.

It would if the field you pointed out would constitute most actual new
C development.

It is a large sample. Add to that another large area, namely GNU, where
the GNU coding standards state:
"1989 Standard C is widespread enough now that it is ok to use its
features in new programs."

"1999 Standard C is not widespread yet, so please do not require its
features in programs."

Then there is embedded SW development.

It is relevant, since you claimed that most new C development in
Windows was not done in C99 because MSVC is the most widely used C
compiler on Windows. My claim that MSVC isn't the only C compiler on
Windows is therefore relevant.

We were talking about what C development is actually done in. The
availability of compilers which are not much used does not affect this.

Saying "your refutation is wrong" is not enough to demonstrate that it
is wrong. I'm afraid your opinion is irrelevant unless you make
arguments about why it is wrong.

You are using the presence of C99 compilers for Windows as evidence that
most development is done in C99. As you have admitted that most Windows
development is done in a compiler that does NOT support C99 that part of
your refutation is clearly wrong. Other parts have been addressed
else-where in this thread.

The problem is actually that you talk about evidence without having
it. With this problem, it isn't even relevant whether people
understand what "evidence" means, since none is even presented.

Your failure to understand the term is relevant because it has presented
you from recognising that some has been presented.

It depends on the case, of course, but what you claimed is that there
was some place where they mention that C99 support is broken, which
they don't.

If the handle of a mug is broken then the mug is broken. The status page
states parts of gcc are broken with respect to C99 so gcc is broken with
respect to C99. You have seen the page which states that parts are
broken, and it even uses that specific word.

Yes, it is safe to assume that. Likewise, it is safe to assume that
your claim is wrong, since it is also wild and unsupported.

So says the person who knows what C implementations are used on the
bases of a massive sample of three?

Anyway, it is rather hard to escape knowledge of K&R as a C programmer.
Do a google search for "C Programming Language" without the quotes and
you hit it.

Some compilers come with a copy of the 2nd edition.

Ask in most places for recommendations of books and someone is likely to
point in that direction.

Ask any old-time C programmer (and new programmers do ask old-time
programmers) and the chances are you will be pointed in that direction.

Eye-witness evidence, I've met far more people who have heard of
Kernighan and Ritchie than have heard of the C standard.

Then those are probably not very competent C programmers, are they?

I don't see a correlation because most of the good developers I have
come across outside this group had not heard of C99.

But you don't know whether most people have heard of the book or of
C99.

Experience suggests that more people have heard of K&R than have heard
of C99.

Whichever is the case, people who know only of one book about C
wouldn't be very good programmers anyway, so making an argument about
them wouldn't be very useful.

Where did I say that K&R was the *only* book they know?

Well, it might be used a lot in embedded programming, but it seems
unrealistic to believe that it is used more in embedded systems than
in actual OSs.

Well, let me count the pieces of kit in this house with embedded SW...
Well, I can think of 20 pieces of kit in this house that definitely have
embedded SW, a lot of those pieces of kit (for example this PC) have
more than one processor and more than one piece of embedded SW (graphics
card has a processor and embedded SW, so does the sound card, the HW,
the DVD drive...).

It's only evidence (if it's true what you said) that shows that a
particular company uses C for embedded systems and not for non-
embedded programming. It's irrelevant as to what *most* C development
takes place on, which is what we were talking about.

It covers a wider range than your experience (I used more than three
different C implementations there) so is more relevant than your
experience. Remember that you have used your experience in argument with
Richard.

I have defined it many times in this thread.

The nearest you have come to defining it is saying that something which
does not conform to C99 is a C99 implementation.

No, they're simply C90 + extensions compilers. (Though a C90 +
extensions compiler will probably also support C90 anyway.)

I've yet to find one that cannot be made to fully conform. I've yet to
find one that with all extensions enabled is not closer to fully
conforming the gcc ever comes to conforming to C99.

No, it isn't, and that sentence is completely unrelated to the rest of
your paragraph.

So you claim that something vaguely close to conforming to C99 is a C99
implementation but something very close to conforming to C90 (which with
a simple switch becomes fully conforming) is not a C90 implementation?

If gcc in *any* mode counts as being a C99 implementation by your rules,
then all implementations in their C90+extensions modes are C90
implementations.

If C90+extensions compilers don't count as C90 implementations (unless
full C90 conformance is enabled) then gcc can't be a C99 implementation
as it is even further away from conformance. Also remember that a lot of
extensions don't affect conformance.

Sure, you're arguing that, but you're not supporting your claims in
any reasonable way, which leads to believe against you.

See above.

I agreed that C90 + extensions development is not C99 development;
that has nothing to do with GCC being or not being a C99 compiler.

It means that all those people using C90+extensions are not using C99.

It is not my main argument for the popularity of C99, and you do not
present any arguments as to why GCC isn't a C99 implementation.

The only other argumens you have given are that:
C99 is the current standard.
Your personal experience.

You have shown that your personal experience is limited (you have only
come across 3 implementations) and C99 being the current standard proves
nothing about how much it is used.

The fact that GCC has a default mode of C90 + extensions shows no
evidence that people are using C90 + extensions, for two logical
reasons: (a) There are other compilers apart from GCC, and

Most of the rest of the compilers around are not C99 compilers.

(b), people
don't always use the default mode.

No, but it is the most common mode.

However, both points are completely unrelated to what you quoted which
was my agreement that C90 + extensions development was not C99
development (which is only logical).

Which was part of a larger argument.

Those new posters are usually beginners. I don't think they would
constitute the majority of C programmers, let alone the most relevant
ones.

Well, the experienced people here recommend using the -ansi -pedentic
switches which put it in to fully C90 conforming mode. So we now have a
sample from beginner to experienced almost all using C90 or C90+extensions.

Not by people who are concerned with portability, since working in
that mode would limit the code to be compiled only under GCC.

I was not talking about people who care about portability since, for
reasons already explained, the majority of them will *not* use C99
because most compilers do not conform to the C99 standard.

You said that by my definition most C90 + extensions compilers are C90
compilers. Regardless of whether that's true, it has nothing to do
with development being in C90 or in C99.

It does when you remember the other bits earlier in the post about why
most people use C90+extensions.

The fact that it's the mode most compilers default to does not mean
that it's the mode most people use.

Experience suggests that most people do nothing to enable compliance to
any standard. Of those who do enable conformance to a standard
experience suggests that most people select C90.

Exactly.

You have been told a lot of things which are indicative and give an
outward sign, some of which you could verify independently. You have
been told a lot of things that would be helpful to most people in
forming a conclusion or judgement.

I'm afraid a single word does not demonstrate much. For example, I
could also claim they conform to C99 by saying that the page
explicitly mentions "conforming" (look around line five), but they do
not actually claim to conform. It's called "taking a word out of
context."

A more complete quote which you have already been given is, "variable
length arrays broken". This being an extract from a table of
features. If the handle of a mug is broken then the mug is broken.

Yes, that's what I've seen so far.

Well, that shows you that there are far more C90 implementations than
C99 implementations. Therefore C90 is far more portable than C99.
Therefore people who really care about portability will have to stick to
C90.

No. I agreed that a broken compiler should be ruled out as being a
<whatever> implementation. That has nothing to do with GCC being or
not being a C99 implementation.

It does. I've now even provided some very simple code that demonstrates
that it is broken.

Well, sure, to /you/.

OK, so you need a hearing aid as well as new glasses.

No. The reason for specifying which compiler to use can be anything.
Here are some clues:

o Compiler X is cheaper than compiler Y
o Compiler X is better than compiler Y
o Management likes compiler X better than compiler Y
o Management simply picks whatever compiler is at hand

Compiler Y not being available would be just another possible such
reason.

All of which are more likely to lead you to having a C90 implementation
that a C99 implementation.

As demonstrated above, management specifying some particular compiler
does not mean that anything else isn't available.

It means that nothing else is available to those developers. That is
what management specifying something means.

How can awareness of a free C90 implementation be irrelevant if
they're looking for a free C90 implementation? Try to make conclusions
that follow the premises; that way you might be able to speak
logically.

I explicitly did NOT say they were looking for a C90 compiler. The
ENTIRE POINT is that you DON'T need to be aware of ANY version of the C
standard to end up with a C90 implementation. Therefore most people WILL
end up with a C90 implementation.

Yes, but you did not talk about choosing a random compiler and using
what it supports; you talked about being aware of free
implementations.

I talked about choosing a compiler for reasons other than wanting
conformance to a particular version of the standard. Unless you can show
some statistical correlation between conformance to versions of the
standard and another desirable attribute then it is effectively random
which standard will be supported with a distribution very skewed towards
C90 implementations due to simple numbers.

Well, since now you're talking about randomly selected compilers: that
randomly selected compiler might not even be a free C90/C99
implementation!

I've already explained the odds.

By that token, it relates to whether they are using _any_ compiler,
regardless of what standard.

Stop talking rubbish. You don't need to be aware of standards *or* free
compilers to use a compiler. You just need a compiler, and the odds are
it will be a C90 compiler.

Yes, you did:

"Those to claims amount to a claim that you believe that Richard's
work is not used in embedded systems" ^^^

Don't say stuff if you're later going to deny you said it.

You keep saying you never claimed that Richard's work IS for embedded
systems. I have never said you claimed Richard's work IS for embedded
systems. I have pointed out that you assumed the OPPOSITE, that
Richard's work is NOT for embedded systems. You just quoted both those
things above.

Not necessarily. At the time I said that they would most likely find
C99 acceptable I wasn't considering what kinds of systems they were
using; I was just thinking in general, and in general, my claim was
true.

What Richard's customers use his code for is entirely relevant to what
will be acceptable.

However, how you misinterpret my posts by assuming implicit claims is
not my problem.

I was pointing out that you are assuming things about his customer base
and that you can only make claims about C99 being acceptable by making
those assumptions.

Richard told me enough in order to make that conclusion when he said
that they don't tell him about their systems, and that they just
assume that whatever he sends them will work on their systems. I then
said that he could send code of any kind and that it would be fine if
they didn't object, to which he agreed. Based on this, Richard's
claims about them not being able to accept C99 was an assumption made
only out of his opinions on C99 availability, which might well be
wrong.

your assumptions are wrong.If Richard has 10 customers and one of them
wants his code for embedded systems then your assumptions are wrong. If
one of his customers insists on using Microsoft Visual Studio (not
uncommon for Windows development) then your assumptions are wrong. If
Richard's code is doing Maths and he uses the C99 atan2 function and his
customers are using gcc on Linux then You assumed a *lot* about his
customers when you claimed that C99 was acceptable.

<snip>

Since you are basing your argument on very limited experience and refuse
to accept anything contrary to your preconceived notions I don't see the
point in continuing this. I've snipped a lot of the rubbish you were
talking. Feel free to have the last word.

 

[s0suk3]

(e-mail address removed) wrote:


The term I was discussing was "C99 implementation", not "C99
installation". You'll find lots of computer people using the second
term; the first term is likely to be used mainly by people interested in
and knowledgeable of the C standard.

Yes, sorry, that was a mistake in my post, but not in the search I
did; I did search for "C99 implementation" (not for "C99
installation"), as shown by the link I provided, and it did yield
17,600 results (without the quotaton marks).

Sebastian

 

[jameskuyper]

Flash Gordon wrote:
....

So how many of those implementations will build the following C99
program and execute it correctly:

#include <stdio.h>
#include <math.h>

int main(void)
{
printf("%f\n",atan2(1,1));
}

The nearest thing I have to a C99 implementation certainly does not.

That's very odd. Can you tell me which feature of C99 it fails to
implement correctly to make that fail?

To save you some trouble I'll let you know that it does not build on Linux.

It builds on my CentOS Linux system with gcc 3.2.3, both in C90
conforming mode and in the closest thing gcc has to a c99 conforming
mode. In C90 mode it gives a warning message about control reaching
the end of a non-void function, but it still compiles, links, and
executes correctly.

On my Irix 6.5 system, using gcc 3.3, it gives the warning for both
C90 and C99, but still compiles and executes correctly. The Irix mips4
compiler has no problem either, despite being only a C90 compiler (in
the version we have installed). It makes a remark about the missing
return statement, but still compiles, links, and executes the program
properly.

 

[Keith Thompson]

Flash Gordon wrote:
...

That's very odd. Can you tell me which feature of C99 it fails to
implement correctly to make that fail?

[...]

It failed for me as well. I was about to post an answer; I'm really
glad I took the time to check the C90 standard before posting.

I suspect both Flash and I made the same mistake: assuming that atan2
is new in C99 (it isn't; C90 has it), and ... drum roll please ...
forgetting to use the "-lm" option.

D'oh!

(But I've *already* read the FAQ!)

 

[Flash Gordon]

Flash Gordon wrote:
...

That's very odd. Can you tell me which feature of C99 it fails to
implement correctly to make that fail?

<snip>

My brain. I should not try building SW after a long day. However,
someone else has posted something which does fail.

 

[Flash Gordon]

Keith Thompson wrote, On 27/08/08 02:54:

Flash Gordon wrote:
...
That's very odd. Can you tell me which feature of C99 it fails to
implement correctly to make that fail?

[...]

It failed for me as well. I was about to post an answer; I'm really
glad I took the time to check the C90 standard before posting.

I suspect both Flash and I made the same mistake: assuming that atan2
is new in C99 (it isn't; C90 has it), and ... drum roll please ...
forgetting to use the "-lm" option.

D'oh!

Indeed. Some of the problems reported on the gcc page would not cause
failure to compile just incorrect results which could be worse.

(But I've *already* read the FAQ!)

I've read that part of the FAQ as well. Oops.