469,266 Members | 1,909 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,266 developers. It's quick & easy.

Storgae durations

what is the difference between the tree storage
durations(static,automatic and dynamic) in C?
Aug 16 '08
241 5674
Ben Bacarisse wrote:
James Kuyper <ja*********@verizon.netwrites:
>jacob navia wrote:
>>Richard Heathfield wrote:
jacob navia said:
...
>>>>He said that C99 wasn't available for IBM mainframes,
No, I didn't. Learn to read, please.

You said that there was no C99 for S390.
Could you give me a citation for that, please? I can't find any such
comment from Richard Heathfield, so I'm probably looking in the wrong
place. The only previous comment I could find from him mentioning S390
is the following (and it mentions OS390, not S390):

Richard Heathfield wrote:
>>s0****@gmail.com said:
...
>>>but let's name five (random) platforms for
illustration:

- Windows
- Linux
- Mac OS X
- Solaris
- HP-UX

By what I'd call "common standards," something that is portable among
that much platforms is very portable.
I think the OS390 and VM/CMS folks might cough and splutter a bit if
they
>>heard you say that
You obviously can't be referring to that message, because it is only a
a comment about how the mainframe people might consider that
definition of "portable" to be absurdly restricted. They would be
right, of course - a definition of "portable" that excludes the most
of the machines for which C code is written nowadays is pretty
ridiculous.

I am used to some pretty adroit verbal gymnastics in c.l.c but is that
really how you read that remark?
Yes, that's precisely how I read it. That required about as much
gymnastics as a stroll through the park. In English, the word 'that'
refers to the most recently mentioned thing that it could reasonably be
considered to apply to.

In this case, 'if they heard you say that' very clearly refers to the
last thing he said, which was "By what I'd call "common standards,"
something that is portable among that much platforms is very portable."
That statement that didn't say anything at all about C99, but was simply
an absurdly restricted definition of "portable", one that OS390 and
VM/CMS people would have obvious reasons to "cough and splutter" over.

It takes quite a bit of verbal gymnastics to misinterpret "to hear you
say that" as referring to anything other than the most recently made
comment. Possibly this is a way in which English differs significantly
from French?
Aug 18 '08 #101
santosh wrote:
Keith Thompson wrote:
....
>Ok, let's look at the article yet again; this is Richard Heathfield
replying to s0****@gmail.com.

| I don't know exactly which platforms are supported by C99
| implementations,
|
| Then you are in no position to make an argument about C99's
| portability or otherwise.
|
| but let's name five (random) platforms for
| illustration:
|
| - Windows
| - Linux
| - Mac OS X
| - Solaris
| - HP-UX
|
| By what I'd call "common standards," something that is portable
| among that much platforms is very portable.
|
| I think the OS390 and VM/CMS folks might cough and splutter a bit if
| they heard you say that. But since you don't actually know whether
| the platforms you name have C99 implementations available for them,
| your point lacks force.

I read it as s0suk3 saying that anything portable to Windows, Linux,
Mac OS X, Solaris, and HP-UX is "very portable", and Richard offering
OS390 and VM/CMS as counterexamples. The surrounding context was
about C99, but the immediate point was about portability. s0suk3 made
a point *about portability*, and Richard responded to it. And it's
being blown completely out of proportion because of jacob's fixation.
....
No. The list that Sebastian made up was intended to serve as a made up
list of C99 supported platforms. Richard's first comment in the quote
above intersects a statement by Sebastian which is *continuing* his
point about C99, not switching from C99 to general portability.
I can't ingure out what you mean by "intersects" here. Richard's comment
occurred at a point when Sebastian's last comment was about portability.
It may have occurred inside the context of other statements that
referred to C99, but Richard's comment was quite clearly about only the
most recently made comment by Sebastian.
Aug 18 '08 #102
s0****@gmail.com said:
Richard Heathfield wrote:
>s0****@gmail.com said:
<snip>
No. Either someone is wrong, or not. It's *that* simple.

You're wrong. It's that simple.

So you're implying that someone can be right /and/ wrong at the same
time, regarding the same subject?
Yes and no.

See?

In the case in point, whether C99 is the "current" standard depends on what
we mean by "current". Implementors have ignored C99 in droves, and most
current implementations conform to C90 but not to C99. There is therefore
little point in holding up C99 as the "current" standard because it's...
well, I won't say it's unimplemented because that's clearly not the case -
but it's not so widely implemented that those who care about portability
can yet reasonably assume that all those who will be compiling their
software have a C99 implementation available. Even on platforms where a
C99 implementation exist, a given customer may not be prepared to lay out
the necessary money to purchase a licence for that implementation.
I don't share your reasoning.
Yes, I know.

<snip>
>>
I'm well aware that the number of Standards exceeds one.

Finally.
Not at all. I've been aware of that since April (or was it May?) 2000, when
Jack Klein posted an announcement of the fact in this very newsgroup.
>
Like I said, they're
*both* C standards. C99 is the *current* standard.

Whether that is true depends on what you mean by the word "current". In
theory ("in law", if you like), you're right - C99 /is/ the current
Standard. In practice, you're wrong - C90 is the current Standard,
because that's the one which is conformed to by the implementations that
people actually use.

What people would those be? I've seen more people use C99 than C90.
That's curious, since you don't use C99 yourself (or at least, that's the
impression I get from your previous articles on the subject). It also
suggests that you have a very, very limited experience of other C
programmers. I've been using C since 1989, and by far the overwhelming
majority of C programmers I've known personally and "met" on the Net use
implementations that conform to C90 but not to C99.
So, even though I don't agree with the "de jure," "de facto," "in
theory" and "in practice" stuff, C99 would be the current standard
even in the way you mean it.
Only if we accept your apparently very limited experience as being typical,
which I certainly don't.
>
>I'm sure I have already explained this to you at least twice.
And no, I never said C89 was obsolete.

Neither did I claim that you had said that.

Well, you said

"*IN PRACTICE*, here you are, advocating C99 and saying that C90 is
obsolete, ..."
Ah, so I did. My mistake. I apologise for getting that wrong.

I was regarding C89 as interchangeable with C90 in this context.
And that is a reasonable thing to do in, as you say, this context.
In fact, I'd recommend using it for
applications that need more portability than C99 offers, or to
maintain legacy code that uses it.

So would I. So we are, after all, in agreement. Good.
And how do you know I don't have a
conforming C99 implementation in my desktop machine?

Logic. You are advocating C99. You claim to use gcc, which is not a C99
compiler.

It is.
Well, that's not what the GNU folks say. VLAs are broken, complex and
imaginary support is broken, and IEC 60559 support is broken. Therefore,
gcc is *close* to being a C99 compiler, but it isn't actually there yet.
Furthermore, glibc has a number of outstanding issues.
>
>Either you have a C99 implementation on your desktop machine or
you don't.

I do.
Then you're using something that isn't gcc. It's curious that you mentioned
gcc, then.

<snip>
The fact that I
use GCC doesn't mean I must *only* have GCC on my machine. I simply
don't think that "conforming" == "perfect", as you seem to think.

That's precisely what "conforming" means.

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

I don't see the word "perfect" in there.
Nor do you see the word "imperfect". The Standard does not give explicit
permission for implementations to be imperfect.
>There's no room in there for imperfection. Either an implementation
conforms or it doesn't.

Of course. Saying "this implementation conforms, but it doesn't," is a
null statement. And I've never said anything like that. BTW, what does
that have to do with an implementation being or not being perfect?
If it doesn't conform perfectly, it's non-conforming.

<snip>
[...] I
think I shouldn't have to mention any further that your standards of
portability are radically different from mine.
That's true. My standard of portability is very simple but (necessarily)
very demanding. Clearly, you're more relaxed about portability, which is
fine, as long as that relaxed attitude meets your needs, which presumably
it does.

<snip>
>[...] Your "proof",
so-called, says that you don't know what you're talking about and you
consider yourself free to re-define your terms as you go along,
therefore you must be right.

No. The fact that my standards for something are different from yours
doesn't mean I'm re-defining anything.
>Sorry, but it doesn't convince me.

But it proves you wrong.
For a proof to prove anything, it has to be convincing. Yours is not.

<snip>
>Those who program in the common subset of C90 and C99 genuinely don't
need to know on which platforms their code will be compiled,

What people would those be?
Those who program in the common subset of C90 and C99, of course.
We're discussing the portability of C89/
C90/C99 here, but we both know that out there in the real world this
isn't as relevant as it may sound here.
It's far more relevant than you seem to realise. Whilst it is certainly
true that many programs require features that are not available in ISO C
and whose models and interfaces differ from platform to platform, it is
also true that a great deal of almost any program can be written portably,
and the portable parts carefully separated from the non-portable parts so
that only the non-portable part need be written for each new platform. My
favourite example is a Web browser product for set-top boxes that was
already well-established when I joined the project, and which comprised
about half a million lines of code, of which 99% (495,000 lines or so) was
written in ISO C - and yes, it was C90, not C99, although C99 had been the
de jure standard for at least a couple of years by then. Every time they
needed to add support for a new platform - which seemed to happen two or
three times a year - they only needed to rewrite around 5000 lines of
code, which took about a month each time. I don't think it's possible to
write a decent modern Web browser in ISO C - but I *do* think it's
possible to write 99% of a decent modern Web browser in ISO C, because
I've seen it done.

<spurious "real world" argument snipped - answered above>

<snip>
I use C99 for my desktop.
>That's a change from your last article, where you claimed you did not
use C99 for your desktop. I don't count non-conforming
implementations, since they don't implement C99.
They do implement C99,

No, they don't.

Yes, they do.
Guess what I'm going to say next - no peeking, now...

No, they don't.
just not completely.

You can't be a little bit pregnant. Either you're pregnant or you're
not.

But a glass of water can be a little full. I'd say my analogy applies
better than yours, but that's something we're never going to agree on,
are we?
No, I don't think we are.

<snip>
>The more I read this, the more I think you've never actually ported code
in your life.

I have, just not in the same way as you.
In what way, then?
It's a similar case for conforming implementations: if it claims to
conform, you can safely use everything the standard defines and as it
defines it. If it doesn't conform, you have to see the documentation
to find out what you can use safely and what not.

No, you can't, because the bits of C99 that *your* implementation
implements correctly might not be the same as the bits of C99 that the
other guy's implementation implements correctly.

But that wasn't my point. My point was, again: you can use safely the
subset of the language that the implementation implements; you just
have to know what you can use and what not. And *that* isn't going to
make the code any less portable, since it will later be compilable
under any conforming implementation.
Counter-example: If you write a program that uses C99-conforming VLAs,
initially for compilation by a truly C99-conforming compiler, you run the
risk that your code won't port to gcc, because gcc's VLAs don't conform
fully to C99.
>The issue here is
portability. A program is (minimally) portable if it can be compiled and
executed correctly (without source code changes) on at least two
implementations. If those two implementations disagree about the
semantics or legality of a construct used by the program, then the
program is *not* portable (without source code changes) between those
two implementations.

You're talking as if I said anything about extensions.
No, I'm not concerned with extensions in this discussion. I'm concerned
with the problems inherent in porting code that assumes a conforming C99
implementation is available, to a platform where there isn't such an
implementation (either because no such implementation exists or because it
hasn't been obtained by the organisation in question).

<snip>
Likewise, many people will agree that compiler-specific extensions are
generally useful.

Sure, and nobody has claimed otherwise as far as I'm aware - but
compiler-specific extensions are not topical here. Similarly, I have on
my desk a fret brush. It's in a tube marked "ghs Fast-Fret" ("Glides on,
wipes off, cleans strings, lets you play faster, brightens sound,
prolongs fingerboard life, long-lasting, won't damage finish, won't soil
or stain, can't spill or break".) Very useful indeed, and I use it
regularly. But it's hardly relevant in comp.lang.c, is it? Same applies
to compiler-specific extensions.

You went more off-topic in that paragraph than I went on mentioning
the words "compiler-specific extensions." So I have to ask: Why do you
talk about your toy on comp.lang.c? :-)
It's an illustration. I use those a lot. The purpose is to assist in
communicating my meaning, in cases where there seems to be some
misunderstanding. I suspect that you are being somewhat disingenuous.

<snip>
Also, I forgot to mention on the previous post: "non-
conforming" != "incorrect".

If it isn't conforming, it isn't a C compiler.

Yes, it is. It simply isn't conforming. Hence the phrase "non-
conforming C implementation."
C89 mentions "nonconforming" once, in non-normative text. C99 mentions
"nonconforming" once (again in non-normative text) and "non-conforming"
twice, in each case referring not to the implementation but to the
program. Either an implementation conforms, or it isn't a C
implementation. There is no such thing as a non-conforming C
implementation because, unless it's a conforming implementation, it isn't
a C implementation.
>If it conforms to C90 but
not to C99, it's a C90 compiler but not a C99 compiler. gcc currently
falls into that category.

GCC is both a C90 and C99 implementation. It conforms to C90, but it
doesn't conform to C99.
Then it's a C90 implementation, but not a C99 implementation.

<snip>
But let's look at a more obvious example of undefined behavior:

You avoided the question. Why did you avoid the question?

The function won't always invoke undefined behavior,
That was the whole point of the example. Compilers can't always tell
whether a function will be used incorrectly at the point where they are
compiling that function. By the time they are compiling the call, they
might not be able to see the function that is being called (because it's
in a different translation unit). It is therefore unreasonable to place
limitations on implementations with regard to undefined behaviour.
so I thought I'd
bring up a more relevant and illustrative example.
....which contains no undefined behaviour whatsoever.
But anyway, what if
we modified the function so that it did something that would *always*
invoke undefined behavior? What do you think the compiler should do
then?
Observe the requirements of the Standard - i.e. do whatever it likes.
Do you think I'd be OK for it to erase all files in the hard
disk?
From a conformance point of view, yes, sure. From a QoI point of view,
that's a matter for the customers to decide.
int i;
int *p = &i;
p++;
In this case, it's obvious to the compiler that the code invokes
undefined behavior,

But it doesn't. It's on the edge of doing so in two ways, but it doesn't
*actually* invoke undefined behaviour.
<snip>
>>

Sorry; I thought it would undoubtedly invoke undefined behavior.
&i doesn't evaluate the indeterminately-valued i, so that's fine, and the
assignment to p is fine. Incrementing p points to "one past" i, which is
(just) fine, as long as the pointer isn't dereferenced, which it isn't.
If a compiler does what I mentioned above
in a case where a program does something that invokes undefined
behavior, I'd deem that compiler useless.
>At the very least, it would be a valuable teaching tool.
But not everyone's on the learning phase, and some people need
productivity.

Their productivity will increase if they have learned to avoid invoking
undefined behaviour unintentionally.

The world isn't perfect. Even the most experienced programmer will
make mistakes and invoke undefined bahavior.
Yes, that's absolutely true. And if the implementation of choice is known
to wipe the disk if it encounters such behaviour (strange implementation
to choose, but hey, you know what managers can be like), then developers
will get a lot of practice in reinstalling operating systems - and, as a
side effect, will learn to be more careful in future. :-)
And a compiler like that would be nothing but useless to
a serious programmer.

Presumably you define "serious programmer" as "programmer who
unintentionally invokes undefined behaviour on a regular basis".

No. In this context, I meant it more as "a programmer that needs to be
as productive as possible, and thus needs the best possible tools
available,
One of my measures of productivity is the amount of code I *don't* have to
rewrite when my code has to work on a new platform.
and a compiler that doesn't erase all files in the hard
disk at the first sign of undefined behavior is the very minimum
requirement."
Well, I do understand that point of view, and mostly (on the UB issue, not
the C99 issue) I guess I'm just arguing for the sake of arguing. Whilst I
would find a pathological implementation fun to use, I wouldn't want it to
be installed on my principal development machine!

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 18 '08 #103
s0****@gmail.com wrote:
<snip>
What people would those be? I've seen more people use C99 than C90.
So, even though I don't agree with the "de jure," "de facto," "in
theory" and "in practice" stuff, C99 would be the current standard
even in the way you mean it.
gcc ist one of the mostly used compilers, another very frequently used one
in M$ Visual C. Neither conforms to C99 nor claim to do so.
So I really dont know how you can see more people using C99 than C89, unless
you're talking about a pretty closed group, like your workmates, all working
on the same platform for which by sheer luck a C99 compiler is available

Bye, Jojo
Aug 18 '08 #104
Nick Keighley wrote:
On 18 Aug, 00:09, jacob navia <ja...@nospam.comwrote:
<snip>
>Just LIES.

no. Gat a dictionary.
I begin to wonder whether the french equivalents to 'lie' and 'false claim'
are the same word? IOW whether in french there's no distiction between a
deliberate wrong claim and an accidental one?

Bye, Jojo
Aug 18 '08 #105
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:

<snip>
>I read it as s0suk3 saying that anything portable to Windows, Linux,
Mac OS X, Solaris, and HP-UX is "very portable", and Richard offering
OS390 and VM/CMS as counterexamples. The surrounding context was
about C99, but the immediate point was about portability. s0suk3 made
a point *about portability*, and Richard responded to it.
Well that is why I said I could, just, get the meaning you seem to
have taken from it, but the surrounding context seems be all the nearby
sentences, both before and after.
Precisely so.
Matter are not helped by the fact you split a sentence. Un-split
(which is the only fair way to read what someone writes) we have:

I don't know exactly which platforms are supported by C99
implementations, but let's name five (random) platforms for
illustration [followed by the list]. But ... something that
is portable among that much platforms is very portable.

You then remark that the OS/390 people might cough and splutter a bit
at that.

This is followed by a sentence (in the same paragraph) that raises
doubts about C99 even for this list. Thus of the four sentences only
one is, apparently, is not about C99 availability.

If OS/390 has a C99 compiler[1], I find it odd that you chose to
insert a comment on general portability by citing a system that does
not suffer from the particular portability problem being discussed.
Nevertheless, if someone as bright as Ben can misinterpret
it, I am beginning to wonder whether I was as clear as I should have been
in my original statement.

The balance (in the general case) is a tricky one. Spelling out every
single nuance of every thought is (a) too time-consuming, and (b)
insulting to my readership, and (c) probably impossible anyway. But my
more usual strategy of leaving people to make what *I* consider to be
obvious and trivial leaps of logic appears to run the risk of being
misunderstood even by bright people.

It never occurred to me, when I was writing a reply to Sebastian's
eyebrow-raising claim that we might paraphrase as "if it works on this
handful of tiny systems, well, that's portable enough for rock n' roll",
that my reply about parochialism might be taken as a claim about C99's
availability or otherwise on mainframe systems.
Sebastian's list was of platforms that (he thought) support C99
implementations which was clear both from the sentence you splint and
that fact that you immediately followed your OS/390 remark by raising
doubts about C99 support. That makes the context so strong that, for
me, clarity would require some sort of re-write.

To me, it reads like this:

S: You can make jelly from lots of fruit.
H: Jam can be made for far more fruit. If you want the widest choice
it has to be jam.
S: Well I don't know exactly what you can and can't make jelly from,
but lets name five (random) fruits for illustration: plums,
raspberries, red currents, black currents, apples. Something you
can make from that many fruit is very flexible.
H: I think the quince growers might splutter a bit if they heard
you say that. But since you don't actually know whether you can
make jelly from the fruit you name, your point lacks force.

Of course you don't say you can't make jelly from quinces, but it read
to me as an odd way to make a general remark about the flexibility of
fruit and special position quinces might (or might not) have.
I must have re-read it a dozen times now, and I still can't see how
it could be interpreted that way. Nevertheless, I recognise that Ben
isn't stupid, so I suppose there must be some way of looking at the
wording that completely changes the meaning.
I don't see it as "completely changing the meaning" to allow the
context from the previous and following sentences to be the reason for
the coughing and spluttering. "That's hardly a representative list of
systems" and "That's hardly a representative list of systems with C99"
are not that far in meaning and with C99 availability bracketing the
remark it is not unreasonable to assume it had some relevance.
Perhaps Ben could
explain how he arrives at that interpretation.
I hope I have shed some light on it. I have been able to see both
readings from the start (one reason I've stay out of the thread) but
one seemed to me so much more likely -- that OS/390 has no C99 and it
is that that would cause all the coughing and spluttering -- that I
was growing more and more perplexed. Of course, it does not help that
Jacon Navia's first response (in this sub-thread) attributed to you a
wild claim that you more certainly never made.

[1] This is still in question. I have seen no reference to a C99
compiler for OS/390 though I am too out of date with IBM letter soup
to know what significance many of the posts have. I would still like
to know if this legacy system has a C99 compiler, despite that having
(it seems) not bearing on this matter. Presumably, Richard, you know
if there is one.

--
Ben.
Aug 18 '08 #106
Nick Keighley <ni******************@hotmail.comwrites:
On 18 Aug, 05:02, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
>James Kuyper <jameskuy...@verizon.netwrites:
jacob navia wrote:
Richard Heathfield wrote:
jacob navia said:
>>>He said that C99 wasn't available for IBM mainframes,
>>No, I didn't. Learn to read, please.
>You said that there was no C99 for S390.
Could you give me a citation for that, please? I can't find any such
comment from Richard Heathfield, so I'm probably looking in the wrong
place. The only previous comment I could find from him mentioning S390
is the following (and it mentions OS390, not S390):
Richard Heathfield wrote:
s0s...@gmail.com said:
...
but let's name five (random) platforms for
illustration:
>> - Windows
- Linux
- Mac OS X
- Solaris
- HP-UX
>>By what I'd call "common standards," something that is portable among
that much platforms is very portable.

this is his definition of "very portable". Note he didn't say there
was a C99 implementation for them.
Actually he did (it has all got clipped and chopped) and Richard goes
on to call that claim (that they have C99) into question in his very
next sentence. Both Sebastian and Richard are talking about C99
availability both before and after the OS/390 remark. This, to me, is
the problem. I have posted elsewhere at more length about this.

I understand perfectly well (now) what was intended, but I think there
is more scope for interpretation than some people seem to suggest.

--
Ben.
Aug 18 '08 #107
James Kuyper <ja*********@verizon.netwrites:
Ben Bacarisse wrote:
>James Kuyper <ja*********@verizon.netwrites:
>>jacob navia wrote:
Richard Heathfield wrote:
jacob navia said:
...
>He said that C99 wasn't available for IBM mainframes,
No, I didn't. Learn to read, please.
>
You said that there was no C99 for S390.
Could you give me a citation for that, please? I can't find any such
comment from Richard Heathfield, so I'm probably looking in the wrong
place. The only previous comment I could find from him mentioning S390
is the following (and it mentions OS390, not S390):

Richard Heathfield wrote:
s0****@gmail.com said:
...
but let's name five (random) platforms for
illustration:
>
- Windows
- Linux
- Mac OS X
- Solaris
- HP-UX
>
By what I'd call "common standards," something that is portable among
that much platforms is very portable.
I think the OS390 and VM/CMS folks might cough and splutter a bit
if
they
heard you say that
You obviously can't be referring to that message, because it is only a
a comment about how the mainframe people might consider that
definition of "portable" to be absurdly restricted. They would be
right, of course - a definition of "portable" that excludes the most
of the machines for which C code is written nowadays is pretty
ridiculous.

I am used to some pretty adroit verbal gymnastics in c.l.c but is that
really how you read that remark?

Yes, that's precisely how I read it. That required about as much
gymnastics as a stroll through the park. In English, the word 'that'
refers to the most recently mentioned thing that it could reasonably
be considered to apply to.

In this case, 'if they heard you say that' very clearly refers to the
last thing he said, which was "By what I'd call "common standards,"
something that is portable among that much platforms is very
portable." That statement that didn't say anything at all about C99,
But is was a statement about C99 availability. By now that fact has
got snipped and the context was further obscured by an another
inserted remark that broke the sentence but Richard certainly knew
this or he would not have continued: "But since you don't actually
know whether the platforms you name have C99 implementations available
for them, your point lacks force". A paragraph break here would have
helped, since then the remark about OS390 would stand on its own.

I am happy to accept the interpretation offered, but it seems to me
the less obvious one, simply because I requires one to drop the
context (C99 availability) and the take it up gain immediately.
It takes quite a bit of verbal gymnastics to misinterpret "to hear you
say that" as referring to anything other than the most recently made
comment. Possibly this is a way in which English differs significantly
from French?
No French involved -- English is my first language. If I
misunderstood then one can assume some other reasonably well-educated
English speakers might do likewise.

--
Ben.
Aug 18 '08 #108
Ben Bacarisse wrote:
James Kuyper <ja*********@verizon.netwrites:
....
I am happy to accept the interpretation offered, but it seems to me
the less obvious one, simply because I requires one to drop the
context (C99 availability) and the take it up gain immediately.
In my experience, general statements are often mixed in with more
specific ones, and comments on those more general ones that don't
limit themselves to the current context are a routine occurrence.
However, to be fair, I also remember a number of very confusing
discussions I've read or participated in which one person missed a
context switch that the other person took for granted.
It takes quite a bit of verbal gymnastics to misinterpret "to hear you
say that" as referring to anything other than the most recently made
comment. Possibly this is a way in which English differs significantly
from French?

No French involved -- English is my first language.
My apologies. I was pretty sure that we had someone from France
posting to this group, other than Jacob. I had mistakenly remembered
you as being that person . It made a certain amount of sense: two
French speakers, same mistaken interpretation. Now I'll have to
abandon that hypothesis. Your interpretation seems far less plausible
to me than what Richard actually intended, but I'll concede that it's
a possible one. I think that the right lesson to learn from this
discussion is that we need to be careful when using words like "he",
"it', or "that", to make sure that it's clear what they refer to.
Aug 18 '08 #109
Ben Bacarisse said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Keith Thompson said:

<snip>
>>I read it as s0suk3 saying that anything portable to Windows, Linux,
Mac OS X, Solaris, and HP-UX is "very portable", and Richard offering
OS390 and VM/CMS as counterexamples. The surrounding context was
about C99, but the immediate point was about portability. s0suk3 made
a point *about portability*, and Richard responded to it.

Well that is why I said I could, just, get the meaning you seem to
have taken from it, but the surrounding context seems be all the nearby
sentences, both before and after.
It seems that several other people interpreted my statement as I intended
it to be interpreted. Now that you have explained your interpretation, I
at least find it a little more understandable, so thanks for that.

<snip>
I have seen no reference to a C99
compiler for OS/390 though I am too out of date with IBM letter soup
to know what significance many of the posts have. I would still like
to know if this legacy system has a C99 compiler, despite that having
(it seems) not bearing on this matter. Presumably, Richard, you know
if there is one.
No, I have no idea. As far as I'm aware, none of my users has installed a
C99 implementation on a mainframe system - but of course it's possible. My
code doesn't care either way, since it's written[1] in the common subset
of C90 and C99, for maximum portability.

[1] At least, I hope it is! :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 18 '08 #110
ja*********@verizon.net wrote:
Ben Bacarisse wrote:
<snip>
>No French involved -- English is my first language.

My apologies. I was pretty sure that we had someone from France
posting to this group, other than Jacob.
That would be Charlie Gordon I suppose.

<snip>

Aug 18 '08 #111
santosh wrote:
ja*********@verizon.net wrote:
Ben Bacarisse wrote:

<snip>
No French involved -- English is my first language.
My apologies. I was pretty sure that we had someone from France
posting to this group, other than Jacob.

That would be Charlie Gordon I suppose.
No, the person I was thinking of had a family name that sounded at
least vaguely french to me. Gordon doesn't qualify, no matter how
French he may actually be - his name recalls Scotland to me, not
France. I just did a moderately exhaustive search, and I couldn't find
any regular poster other than Ben whose name was a good fit to my
memory. There's a good reason why I normally rely upon pen and paper,
or electronic storage media, rather than my own memory :-(.
Aug 18 '08 #112
ja*********@verizon.net writes:
santosh wrote:
>ja*********@verizon.net wrote:
Ben Bacarisse wrote:

<snip>
>No French involved -- English is my first language.

My apologies. I was pretty sure that we had someone from France
posting to this group, other than Jacob.

That would be Charlie Gordon I suppose.

No, the person I was thinking of had a family name that sounded at
least vaguely french to me. Gordon doesn't qualify, no matter how
French he may actually be - his name recalls Scotland to me, not
France. I just did a moderately exhaustive search, and I couldn't find
any regular poster other than Ben whose name was a good fit to my
memory. There's a good reason why I normally rely upon pen and paper,
or electronic storage media, rather than my own memory :-(.
If you are looking for a french speaking Belgian living in France, I'm
here. But I'm far from a regular poster.

Yours,

--
Jean-Marc
Aug 18 '08 #113
On Monday 18 August 2008 21:13, Jean-Marc Bourguet wrote:
ja*********@verizon.net writes:
>santosh wrote:
>>ja*********@verizon.net wrote:
Ben Bacarisse wrote:

<snip>

No French involved -- English is my first language.

My apologies. I was pretty sure that we had someone from France
posting to this group, other than Jacob.

That would be Charlie Gordon I suppose.

No, the person I was thinking of had a family name that sounded at
least vaguely french to me. Gordon doesn't qualify, no matter how
French he may actually be - his name recalls Scotland to me, not
France. I just did a moderately exhaustive search, and I couldn't
find any regular poster other than Ben whose name was a good fit to
my memory. There's a good reason why I normally rely upon pen and
paper, or electronic storage media, rather than my own memory :-(.

If you are looking for a french speaking Belgian living in France, I'm
here. But I'm far from a regular poster.
Well, I'm a French speaking Canadian living in Belgium and I'm probably
even less of a regular poster :-)

Cheers,
JFL
--
Jean-François Lemaire
Aug 18 '08 #114
ja*********@verizon.net writes:
santosh wrote:
>ja*********@verizon.net wrote:
Ben Bacarisse wrote:

<snip>
>No French involved -- English is my first language.

My apologies. I was pretty sure that we had someone from France
posting to this group, other than Jacob.

That would be Charlie Gordon I suppose.

No, the person I was thinking of had a family name that sounded at
least vaguely french to me.
My name is French and I have spoken of it here due to the (slight)
irony that Jacob Navia has miss-spelt it more than once. May be you
filed this information as "Ben speaks/is French".

--
Ben.
Aug 18 '08 #115
Ben Bacarisse wrote:
....
My name is French and I have spoken of it here due to the (slight)
irony that Jacob Navia has miss-spelt it more than once. May be you
filed this information as "Ben speaks/is French".
Thanks! With that hint, I now remember that this is what happened. My
memory has always been somewhat unreliable, and is getting more so,
but it's not completely unreliable - yet.
Aug 18 '08 #116
On 17 Aug 2008 at 23:31, Ian Collins wrote:
jacob navia wrote:
>vi******@gmail.com wrote:
>>On Aug 18, 2:13 am, jacob navia <ja...@nospam.comwrote:
How many times do I have to prove Heathfield wrong?

Before what? Before you stop acting like a lunatic?

Your answer is typical mr. If I prove heathfield wrong
I am a lunatic OF COURSE!
The proof is irrelevant, it's the incessant ranting that puts people's
backs up.
I think it only puts up the backs of people who've already decided to
join in Heathfield's puerile bullying campaign of Jacob.

Do you really believe that Mr "Heathfield"'s smug, smarmy,
self-satisfied arrogance, or Mr "Vip Star"'s semi-psychotic posts do
less to "put people's backs up"?

Aug 18 '08 #117
On 18 Aug 2008 at 14:02, Richard Heathfield wrote:
s0****@gmail.com said:
>So you're implying that someone can be right /and/ wrong at the same
time, regarding the same subject?

Yes and no.
[reams and reams of similar nonsense snipped]

Heathfield is the master of subterfuge and equivocation. Trying to argue
against his word games is a complete waste of time and energy, and will
only provoke a deep frustration that obviously brings Heathfield a
perverse sense of satisfaction.

When even the placid Ben Becarisse accuses Heathfield of deliberately
laying a trap for Jacob in this thread, can there be any doubt of his
bad faith and dishonesty?

Aug 18 '08 #118
On 18 Aug 2008 at 8:35, Nick Keighley wrote:
He DID NOT SAY OS390 (z/VM) DID NOT HAVE A CONFORMING C99 COMPILER.
Of course not. Heathfield doesn't deal in plain statements, but in word
games, smoke and mirrors. He very very clearly *implied* that S390
doesn't have a conforming C99 compiler, but as with any illusionist he
allowed himself enough wiggle room to pull back and claim he said
something with no meaning instead.

Aug 18 '08 #119
On 18 Aug 2008 at 14:28, Joachim Schmitz wrote:
I begin to wonder whether the french equivalents to 'lie' and 'false claim'
are the same word? IOW whether in french there's no distiction between a
deliberate wrong claim and an accidental one?
In this case, Heathfield's wrong claim was certainly deliberate. As a
native English speaker, I call that a LIE.

Aug 18 '08 #120
ja*********@verizon.net said:
santosh wrote:
>ja*********@verizon.net wrote:
Ben Bacarisse wrote:

<snip>
>No French involved -- English is my first language.

My apologies. I was pretty sure that we had someone from France
posting to this group, other than Jacob.

That would be Charlie Gordon I suppose.

No, the person I was thinking of had a family name that sounded at
least vaguely french to me.
Possibly you are thinking of Emmanuel Delahaye, who (as far as I am aware)
is genuinely French.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 19 '08 #121
s0****@gmail.com writes:
[...]
Like I've said, I only say it's a C99 implementation because you can
compile C99 programs in it and because it supports most of C99 (i.e.,
it's common sense).
A pure C90 implementation with no extensions also supports most of
C99.
Have they actually said, "we don't have a C99
implementation"? If so, could you point me to the site where it's
stated?
It's implied by <http://gcc.gnu.org/c99status.html>, unless you insist
on referring to implementation that doesn't fully conform to the C99
standard as a "C99 implementation".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 19 '08 #122
On Aug 19, 12:20 am, Keith Thompson <ks***@mib.orgwrote:
s0****@gmail.com writes:

[...]
Like I've said, I only say it's a C99 implementation because you can
compile C99 programs in it and because it supports most of C99 (i.e.,
it's common sense).

A pure C90 implementation with no extensions also supports most of
C99.
Technically, yes. But this isn't the case of most compilers that claim
to support C99, such as GCC, where you normally don't even note the
failures, unless you go see the website.

I was also talking about usability. Clearly a compiler that would
claim to support C99 by only implementing the subset that corresponds
to C90 wouldn't be as useful as one that actually tries to implement
most C99 features (if you're using C99).
Have they actually said, "we don't have a C99
implementation"? If so, could you point me to the site where it's
stated?

It's implied by <http://gcc.gnu.org/c99status.html>,
The site marks the features and failures of C99 in GCC. Where does say
that they don't have a C99 implementation? The most relevant part I
found regarding this subject is

"This page describes the C99 support in mainline GCC, not in any
particular release."
unless you insist
on referring to implementation that doesn't fully conform to the C99
standard as a "C99 implementation".
That's precisely what I've been saying.

Sebastian

Aug 19 '08 #123
s0****@gmail.com said:
On Aug 18, 9:23 pm, Richard Heathfield <rj*@see.sig.invalidwrote:
<snip>
>>
It is you who claim that things have changed - that most people now use
C99. The burden of proof is therefore on you. (Saying "it's so" does not
constitute proof.)

That's clearly something nearly impossible to prove.
Yes, it's certainly very difficult to prove something that isn't true.
And I didn't say
"it's so," I said "We've yet got to see if that's true, or if it's the
contrary," which isn't even an affirmation.
Fine. By the same token, we've yet got to see whether it's true that Elvis
is alive but was carried off by aliens. Nevertheless, until proof to the
contrary emerges, I am content to accept the most likely scenario - i.e.
that the King is dead. Likewise, until proof to the contrary emerges, I am
content to accept the most likely scenario - i.e. that most C programmers
are not using C99-conforming implementations.
Whether things change or not is not a possibility, though; it's a
fact: if time passes, things change. There's for example the
(diminutive) possibility that C99 was the most widely used standard in
the minute it was available, but I think something like that would be
impossible to prove.
Since the first C99-conforming implementation appeared some considerable
time (a lot more than a minute) after the C99 Standard was adopted, I am
content to accept the most likely scenario - i.e. that it did not become
the most widely used standard from the minute it was available.
So the point is that it's just as impossible to
prove that C99 is more widely used than C90 as it is impossible to
prove the opposite.
Nevertheless, in the absence of - at the very least - some kind of credible
supporting evidence, I accept the most likely scenario, i.e. that C99 is
not as widely used as C90 by a very, very long way indeed.

<snip>
>especially since there is this growing trend for people to use free
software if they can, and (as far as I'm aware) there isn't yet a
single free C99-conforming implementation.
I don't know much about compilers, but even I have heard about Intel.

Perhaps you'd be so kind as to point out where Intel claim C99
conformance.

At their site:

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

<snip>
>[...] everybody and his dog has a C90-conforming
implementation, and of course there are plenty of free C90
implementations.
So is the case for C99.

Perhaps you'd be so kind as to provide some URLs.

Whenever you're so kind as to provide URLs that prove that everybody
and his dog has a C90-conforming implementation.
Do you really, really, really think they haven't? C90 is probably the most
widely implemented language standard ever!

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

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

These compilers provide support for PCs running MS-DOS, Windows (various
flavours), Linux, Unix (various flavours); for MacOS; for a number of
mainframe operating systems; for a whole bunch of DSPs; for PDAs such as
the Palm; and many many more.
><snip>
I've seen more people use C99 than C90.
>That's curious, since you don't use C99 yourself (or at least,
that's the impression I get from your previous articles on the
subject).
You continue to (extremely) misinterpret the same things in the
same ways.
>Well, so far the only implementation you've mentioned using is gcc,
which doesn't conform to C99.
That's not what I was denying.

It's not clear what you're denying (other than reality, of course).

You said

"That's curious, since you don't use C99 yourself"

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

"Well, so far the only implementation you've mentioned using is gcc,
which doesn't conform to C99."

which is not the same thing, and therefore is not what I denied.
You're weaselling. Either you use a conforming C99 implementation or you
don't. Decide.
><snip>
But what I meant is that people starting
to write new apps usually choose C99.
>Given that most people starting to write new apps don't actually have
a C99 implementation,
False.

If you are so confident that I'm wrong, you should have no difficulty in
demonstrating this. Please feel free to try.

Neither did you demonstrate that you were right. (And there's no way
to do that.)
My point is that your statement, "False" (quoted above), is unsupportable.

<snip>
When have I claimed that I'm using a conforming C99 implementation by
using GCC?
Cut to the chase. Are you using a conforming C99 implementation? (gcc isn't
one.)

<snip>
>Sorry, but it doesn't convince me.
But it proves you wrong.
>For a proof to prove anything, it has to be convincing. Yours is
not.
I thought it was convincing.
>Yes. Many "provers" think their "proofs" are convincing. But proofs
have to convince **other people**. Your "proofs" certainly don't
convince me.
"Proofs" are usually rejected by the person being proved against.

If acceptance of the proof is a matter of opinion, it's not really a
proof, is it?

You yourself said: "For a proof to prove anything, it has to be
convincing." That suggests that it's a matter of opinion, since,
according to the dictionary, "convincing" means: "appearing worthy of
belief." So if someone believes it, it's that person's opinion that
it's true.
Let me give you an example of a proof, using this (rather badly-drawn)
diagram:

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

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

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

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

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

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

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

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

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

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

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

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

Subtracting 2ab from both sides:

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

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

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

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

(you)
I don't know exactly which platforms are supported by C99
implementations,
(me)
>Then you are in no position to make an argument about C99's
portability or otherwise.
(you)
I am if my standards of portability comprise an implementation being
portable among a number of fairly popular and widely used OSs, and if
there are implementations for C99 that target those platforms.
+++++++++++++++++++++++++++++++++++++++++++++++++

Your "proof" changed the focus from C99's portability - an objective
concept - to your standards of portability - a subjective concept. It also
begged the question (i.e. it assumed the thing you were trying to prove -
that C99 programs are widely portable). Furthermore, it made improper use
of an implicit assumption that the mere availability of a C99
implementation for a platform indicates that a significantly large
proportion of C developers using that platform have obtained a copy of
that implementation.

<snip>
Anyway, what you mention is
generally not so important, since GNU supports C99, even though it
doesn't conform.

It may not be important to *you*, but it's important to people who need
to know that their code will work on multiple implementations.

Limiting the code to a subset of the language won't reduce
portability.
That is precisely why I limit my code to the subset of C99 that is also
legal C90.

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

Hilarious. If they don't tell you anything about their system, how can
you know they even have a C90 implementation?
Because everybody and his dog has a C90 implementation.

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

That makes the whole point null.
Not at all.

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

Like I've said, I only say it's a C99 implementation because you can
compile C99 programs in it and because it supports most of C99 (i.e.,
it's common sense). Have they actually said, "we don't have a C99
implementation"?
I don't know whether they've ever used those precise words, but...
If so, could you point me to the site where it's stated?
.... http://gcc.gnu.org/c99status.html makes it very clear.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 19 '08 #124
s0****@gmail.com wrote:
On Aug 18, 9:02 am, Richard Heathfield <rj*@see.sig.invalidwrote:
[about value of portable code]

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

It isn't possible to write anything that even nearly resembles a Web
browser in ISO C. A modern Web browser depends heavily on things like
Graphical User Interfaces, networking, threading, and OS environment
stuff. If 1% of the code did this things, what in heaven did the other
99%?
Things may be different for set-top boxes though I'm not sure. Certainly
graphics can be done in 100% ISO C if the OS allowed full privileges to
the program. Cooperative multitasking can be implemented in the place
of preemptive threading. Most of the networking too can be done in ISO
C except for the actual transfer which is simply an OS API call. The
meat of a web browser is of course the HTML parser and renderer, as
well code for HTTP, FTP, SSL, TLS etc. etc., all of which can be done
in ISO C except for the interface to the outside world, which is simply
an OS call or two. It won't be strictly conforming C, but it *can* be
highly portable C nevertheless.

Aug 19 '08 #125
s0****@gmail.com writes:
On Aug 19, 12:20 am, Keith Thompson <ks***@mib.orgwrote:
>s0****@gmail.com writes:
[...]
Have they actually said, "we don't have a C99
implementation"? If so, could you point me to the site where it's
stated?

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

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

"This page describes the C99 support in mainline GCC, not in any
particular release."
>unless you insist
on referring to implementation that doesn't fully conform to the C99
standard as a "C99 implementation".

That's precisely what I've been saying.
Then we have a disagreement over terminology.

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

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

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

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 19 '08 #126
Keith Thompson wrote:
s0****@gmail.com writes:
[...]
>Like I've said, I only say it's a C99 implementation because you can
compile C99 programs in it and because it supports most of C99 (i.e.,
it's common sense).

A pure C90 implementation with no extensions also supports most of
C99.
> Have they actually said, "we don't have a C99
implementation"? If so, could you point me to the site where it's
stated?

It's implied by <http://gcc.gnu.org/c99status.html>, unless you insist
on referring to implementation that doesn't fully conform to the C99
standard as a "C99 implementation".
That's precisely their bone of contention. Richard's definition
of "conforming implementation", and which the Standard also states, is
one which implements (modulo bugs) *all* the mandatory semantics and
features of the Standard. This is a demanding but reasonable
definition. C90 *was* implemented fully by the majority of C compilers
and one would've have expected the same for the current C Standard.
That it didn't happen is disappointing.

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

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

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

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

Aug 19 '08 #127
Richard Heathfield <rj*@see.sig.invalidwrites:

Gjacob navia said:
>
>Richard Heathfield wrote:
>>>But the important thing is not so much the conformance
level,

The important thing to you, maybe - but here, we discuss ISO C, not
notquiteISO C.

Yes, sure.

But with ISO C you do not mean ISO C, but an
obsolete version of ISO C that suits your tastes.

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

>So, here, you say, "we" discuss whatever "you" like.

No, in late 2007 this was debated at length, and the group decided
*against* extending topicality, despite the opinions of those who,
like
No. You and a few sycophants discussed it. Since most people have you
and your clique killfiled because of your constant rudeness and ego
mania then most didn't even see this "discussion".
Aug 19 '08 #128
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
>Richard Heathfield <rj*@see.sig.invalidwrites:

<snip>
>>>
"supports C99" and "conforms to C99" have different meanings.

I suppose so, but the statement that it "Supports" the C99 standard
strongly implies that it conforms to it.

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

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

Amazing. Even for you.
Aug 19 '08 #129
Richard Heathfield <rj*@see.sig.invalidwrites:
s0****@gmail.com said:
>On Aug 18, 7:28 pm, Richard Heathfield <rj*@see.sig.invalidwrote:
>>s0****@gmail.com said:

On Aug 18, 9:02 am, Richard Heathfield <rj*@see.sig.invalidwrote:

<snip>

In the case in point, whether C99 is the "current" standard depends
on what we mean by "current".

Well, the dictionary says "passing in time; belonging to the time
actually passing." That's the way I meant it in this context too.

Fine. Then C90 is the current Standard, because it's the one people
actually program against, *now* - well, most people, anyway.

We've yet got to see if that's true, or if it's the contrary.

It is not in dispute that C90 *was* the Standard against which people
programmed (because this was certainly the case before C99 existed). It is
you who claim that things have changed - that most people now use C99. The
burden of proof is therefore on you. (Saying "it's so" does not constitute
proof.)
It is as valid to ask you to prove your claims that C90 is the dominant force.
Aug 19 '08 #130
Richard Heathfield wrote:

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

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

Aug 19 '08 #131
Richard Heathfield <rj*@see.sig.invalidwrites:
Barry Schwarz said:
>On Sun, 17 Aug 2008 07:32:45 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:
<snip>
>>>Yes, there are lots of implementations that "support" C99 to a greater or
lesser extent. I see no hard evidence that the implementation you mention
even *claims* C99 conformance, however. Perhaps I missed it, in which
case no doubt you can point out where the conformance claim is made.

Hardly surprising since that page is a marketing puff piece. If you
follow the links to documentation, you can find IBM document
SC09-4767-06, "z/OS XL C/C++ User’s Guide". On page 561 they state:

c89 ... Use this invocation for strict conformance to the ISO/IEC
9899:1990 standard.

c99 ... Use this invocation for strict conformance to the ISO/IEC
9899:1999 standard.

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

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

Aug 19 '08 #132
Richard wrote:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Keith Thompson said:
>>Richard Heathfield <rj*@see.sig.invalidwrites:

<snip>
>>>>
"supports C99" and "conforms to C99" have different meanings.

I suppose so, but the statement that it "Supports" the C99 standard
strongly implies that it conforms to it.

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

So to support your ridiculous attempts at twisting things you quote
someone most people have never heard of who mislead people?
Greg Comeau has been a semi-regular participant here for at least as
long as I have been participating and very probably for much longer
(Google Groups will show this). He has been on the Committees for C and
C++ and his implementation (Comeau C/C++) is high quality one, by all
the looks of it.

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

Despite your contempt for RH, you should try not to impulsively lash out
at everyone else too.
Amazing. Even for you.
Aug 19 '08 #133
Richard wrote:
Richard Heathfield <rj*@see.sig.invalidwrites:

Gjacob navia said:
>>
>>Richard Heathfield wrote:
But the important thing is not so much the conformance
level,

The important thing to you, maybe - but here, we discuss ISO C, not
notquiteISO C.
Yes, sure.

But with ISO C you do not mean ISO C, but an
obsolete version of ISO C that suits your tastes.

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

>>So, here, you say, "we" discuss whatever "you" like.

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

No. You and a few sycophants discussed it. Since most people have you
and your clique killfiled because of your constant rudeness and ego
mania then most didn't even see this "discussion".
Funnily enough, I suspect that most people have actually killfiled you
and your two "fellows in arms", Twink and McCormack.

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

Aug 19 '08 #134
santosh wrote:
<snip>
Personally, I don't believe in (or use) killfiles.
Same here. I apply a virtual killfile on a case by case basis.
Seems usefull on part-time trolls. And trolls in this group, that don't
troll in others

Bye, Jojo
Aug 19 '08 #135
santosh <sa*********@gmail.comwrites:
Richard wrote:
>Richard Heathfield <rj*@see.sig.invalidwrites:

Gjacob navia said:
>>>
Richard Heathfield wrote:
>But the important thing is not so much the conformance
>level,
>
The important thing to you, maybe - but here, we discuss ISO C, not
notquiteISO C.
>

Yes, sure.

But with ISO C you do not mean ISO C, but an
obsolete version of ISO C that suits your tastes.

No, I mean ISO C. That certainly includes C99. It also includes C90.
So, here, you say, "we" discuss whatever "you" like.

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

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

Funnily enough, I suspect that most people have actually killfiled you
and your two "fellows in arms", Twink and McCormack.
I suspect most of the clique have indeed. Because they dont like having
their contributions dissected and laughed at.

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

You see I, and I suspect kenny and twink, really do have real industry
experience on big projects. So we *know* how much bullshit certain
posters here produce. We dont say these claims are "impossible" we just
say that most of these claims have no place in a public group where some
people might think these claims are the norm. Claims of fixing 50,000
line programs (someone elses) from a glance at the printout are such
claims that cause me to chuckle and shake my head. Can one do it? Of
course one MIGHT do it. Of course some people HAVE done it. Would any
analyst programmer worth his salt recommend that as the way to do it? Of
course not. That ridiculous quote from Kernighan bandied around by one
of the more self important regs makes we want to give him (the poster) a
poke in the eye :-;
>
Personally, I don't believe in (or use) killfiles.
Me neither. As a general rule. Although I finally had to add
Bwian (Default Loser), Bill, and "Chuck" since their trolling and net
nannying bordered on the ridiculous. heathfield was in there (his ego
makes me cringe) but auto scoring popped him out again recently. But
having seen hos continued lies and agenda against Jacob he might just
have to go back in. Which is a shame - since if you can stomach his
preening arrogance and read between the lines of his convoluted "look
how clever I am" English grammar he certainly knows a lot about an old
C standard (although how applicable that is in the modern day is
debatable).

Aug 19 '08 #136
santosh said:

<snip>
Whether a "non-conforming" C implementation or a "nearly conforming"
implementation like GCC (to C99 of course) is usable is rather
subjective. Some programmers are naturally "tool oriented" and prefer
to fully use powerful tools and don't care much about maximal
portability or standard's conformance, while some others are
naturally "standards oriented" and prefer to (as strictly as possible)
follow ratified and de facto standards (and note that a sufficiently
popular tool can itself become a "de facto" standard, so there is a
thin line between what one might consider standard and what not.)
All true, of course.
The extremes of both positions are almost impossible and the position
one must adopt on this line for a particular project depends on it's
requirements, and our prior experience (aka common sense.)
Coding for portability even with weird implementations is very challenging,
and in practice it is probable that very few people even attempt it.
Everybody draws a line, as you rightly point out, and the question is
where to draw it. This is very likely to vary from project to project and
indeed from programmer (or chief horse-whipper) to programmer (or chief
horse-whipper).

Some obvious points of diversion on portability and robustness:

* using/not using extensions (and how much to abstract them if you do)
* using/not using C99isms
* catering for non-ASCII platforms
* catering for big bytes
* dealing with potential overflow
* dealing with malloc failures

No doubt I've missed a few.

Perhaps the biggest sticking point for me is big bytes. It is often very,
very convenient to get yourself an array of UCHAR_MAX + 1 unsigned longs
(or whatever), for a variety of text processing purposes, but this can go
horribly wrong if UCHAR_MAX is unexpectedly colossal.
This is an interesting issue, but unfortunately the present participants
are rather entrenched in their opposing positions and the discussion
has descended into claims for "proof" and word wrangling.
Foo to that! :-) Threaded newsreaders make it not only possible but easy
for people to participate in the interesting parts of the discussion and
ignore, at their discretion, the boring tis-tisn't bits.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 19 '08 #137
santosh wrote:
....
Things may be different for set-top boxes though I'm not sure. Certainly
graphics can be done in 100% ISO C if the OS allowed full privileges to
the program.
....
an OS call or two. It won't be strictly conforming C, but it *can* be
highly portable C nevertheless.
If it's not strictly conforming, how can you justify calling it "100%
ISO C"?
Aug 19 '08 #138
James Kuyper wrote:
santosh wrote:
...
>Things may be different for set-top boxes though I'm not sure.
Certainly graphics can be done in 100% ISO C if the OS allowed full
privileges to the program.
...
>an OS call or two. It won't be strictly conforming C, but it *can* be
highly portable C nevertheless.

If it's not strictly conforming, how can you justify calling it "100%
ISO C"?
Because ISO C includes conforming as well as strictly conforming
programs and the former are allowed to use extensions. The following C
code fragment

/* process HTML and build image */
load_image();
update_screen();

*is* 100% ISO C provided we do not include the contents of load_image
and update_screen and simply consider only their published interface.
But this is not strictly conforming C code.

Or am I making a fundamental bad assumption somewhere?

Aug 19 '08 #139
In article <g8**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
....
>Was this said with gritted teeth? Since it makes you look like a
complete and utter dickhead.

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

And, when you think about it, that's not a pretty picture.

Oh, oh. I think I've just ruined my whole day...

Aug 19 '08 #140
santosh said:
Richard wrote:
>Richard Heathfield <rj*@see.sig.invalidwrites:

Gjacob navia said:
>>>
<snip>
>>>
So, here, you say, "we" discuss whatever "you" like.

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

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

Funnily enough, I suspect that most people have actually killfiled you
and your two "fellows in arms", Twink and McCormack.
Even funnier is that one of these "sycophants" posted this:

<7v************@news.individual.net>

Isn't that sweet?

(Incidentally, the views on topicality expressed in that article are
remarkably similar to my own.)

The lovely thing about trolls is that they don't have to be consistent.
They just make up any old junk, in the hope that people aren't paying
attention. Whenever they make a claim, never *ever* take it on trust.
Check it out. Chances are that they're either mistaken or lying through
their teeth. I wouldn't trust your correspondent to get the day of the
week right.

Personally, I don't believe in (or use) killfiles.
Well, obviously that's your choice, but it would save you a lot of time.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 19 '08 #141
santosh said:
Richard Heathfield wrote:

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

BTW, is it technically possible for an ISO standard to be withdrawn and
replaced with the previous version?
I don't know (comp.std.c might be a good place to ask that) - but I suppose
they could simply release a brand new version (say, C1X) that just so
happens to be identical to a previous version (e.g. C90). I'm given to
understand that the C committee is giving serious consideration to
back-pedalling quite a bit on C99, although I doubt very much whether
they'll scrap the whole thing.
Coming back to Standard C, perhaps WG14 could have taken out the least
implemented parts of C99 (such as complex.h, tgmath.h, stdint.h, VLA,
fenv.h etc.) and put them in an annexes for optional features, much
like annexe F of the current Standard. This wouldn't change things on
the ground, but it would mean that a lot more implementations can apply
to themselves the label "conforming", which increases the "feel good"
factor, which seems to be often more important than worthier
considerations.
I think they're considering something very like this, although I don't know
the details. Again, comp.std.c would be the people to ask.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 19 '08 #142
s0****@gmail.com said:
Richard Heathfield wrote:
>s0****@gmail.com said:
Richard Heathfield wrote:
>It is you who claim that things have changed - that most people now
use C99. The burden of proof is therefore on you. (Saying "it's so"
does not constitute proof.)
That's clearly something nearly impossible to prove.

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

You don't know whether it's true or not.
"Kid, I've flown from one side of this galaxy to the other, and I've seen a
lot of strange stuff, but I've never seen anyone use a C99
implementation", as Han Solo nearly said. How many horses must you count,
and how many times must you *not* see a unicorn, before you're allowed to
say that unicorns aren't as common as horses?

<snip>
You said
"That's curious, since you don't use C99 yourself"
which I denied.

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

No.

And I never claimed I did.

I said I used a C99 implementation.
So you are drawing a distinction between "C99 implementation" and
"conforming C99 implementation". I would argue that there is no such
distinction - that an implementation either conforms, or does not conform,
to C99. There is no middle ground.

<snip>
>[...] Either you use a conforming C99 implementation or you
don't. Decide.

No.

And I never claimed I did.
Fine. We have now established that you do not use a conforming C99
implementation. Good. Since an implementation that does not conform to C99
is not a C99 implementation, we have also established that you do not use
a C99 implementation. Good. Finally.
[...] 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.
Do I really need to say anything
else but "False"?
Well, "True" would have been a lot closer to the mark, wouldn't it?

<snip>
It's as simple as this: Not everything is as exact and concise as
mathematics.
Nevertheless, we can say with exactness and concision that implementations
either do, or do not, conform to C99.

<snip>
>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. I don't even know
whether you realise your argument made that assumption. Nevertheless, make
it it did. It's as if we were to suggest that the majority of people drive
Porsches because they are available in both left-hand-drive and
right-hand-drive. But there are other relevant factors! Not everyone can
afford a Porsche (or a C99 implementation). Of those who can, not everyone
likes them. Of those who do, not everyone is in control of the decision to
buy or not buy one. Of those who are, not everyone necessarily wants to
spend the money in that way. (Yes, I know Intel C is free - or at least,
I'm prepared to take your word for it - but the point is nevertheless
valid. Not everyone uses a platform supported by Intel.)

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

Well if they don't object to you the first time you send them code
they can't compile, it's only logical to assume they do have a C90
implementation. So the bottom line is that it would be equally
acceptable to send them any code: C99, C++, Java! :-) And if they
don't object, then it means it's OK.
Yes, that's a perfectly reasonable point - until, of course, they /do/
object. And that is precisely what would happen if I started littering my
code with C99isms.

<snip>
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.html makes it very clear.

Like I already told Keith, they don't mention that there.
Yes, they do, by listing the ways in which their implementation does not
conform to C99.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 19 '08 #143
santosh wrote:
James Kuyper wrote:
>santosh wrote:
...
>>Things may be different for set-top boxes though I'm not sure.
Certainly graphics can be done in 100% ISO C if the OS allowed full
privileges to the program.
...
>>an OS call or two. It won't be strictly conforming C, but it *can* be
highly portable C nevertheless.
If it's not strictly conforming, how can you justify calling it "100%
ISO C"?

Because ISO C includes conforming as well as strictly conforming
programs and the former are allowed to use extensions.
There's nothing that defines what "100% ISO C" means, but I don't think
you can justify calling something 100% ISO C just because it is a
conforming C program. Lincoln's Gettysburg Address is a conforming C
program. Would you call it 100% ISO C?

The C standard defines only two named conformance levels for code:
"conforming" is a uselessly broad category which was invented for purely
political reasons to get the standard approved - it's not possible to
come up with anything that isn't in that category. "strictly conforming"
is a category so strict that it is almost useless. "No mandatory
diagnostics and no undefined behavior" is my personal choice for minimal
conformance, but there's no official name for code meeting those
requirements.
... The following C
code fragment

/* process HTML and build image */
load_image();
update_screen();

*is* 100% ISO C provided we do not include the contents of load_image
and update_screen and simply consider only their published interface.
But this is not strictly conforming C code.

Or am I making a fundamental bad assumption somewhere?
The library that defines those functions cannot be written in strictly
conforming C; at least some part of it must be written either in some
other language, such as assembler, or in C code with behavior that is
undefined by the C standard. Linking your code to that library renders
the behavior of your program undefined by the C standard. Something else
can define that behavior, but when the C standard says that the behavior
of a program is undefined, I have trouble understanding how you could
call it 100% ISO C.
Aug 19 '08 #144
Richard Heathfield <rj*@see.sig.invalidwrites:
santosh said:
[...]
>BTW, is it technically possible for an ISO standard to be withdrawn and
replaced with the previous version?

I don't know (comp.std.c might be a good place to ask that) - but I suppose
they could simply release a brand new version (say, C1X) that just so
happens to be identical to a previous version (e.g. C90). I'm given to
understand that the C committee is giving serious consideration to
back-pedalling quite a bit on C99, although I doubt very much whether
they'll scrap the whole thing.
[...]

I recently asked about this in comp.std.c, in the discussion about the
new C1X draft:
There have been rumors about some C99-specific features being
dropped; there's no sign of that here.
As far as I know, no one has made any concrete proposals along those
lines.

The response was from Larry Jones, a committee member.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 19 '08 #145
santosh wrote:

[More feeding of the troll]
Personally, I don't believe in (or use) killfiles.

We can tell.


Brian
Aug 19 '08 #146
On Aug 19, 7:19 am, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@gmail.com said:
Richard Heathfield wrote:
s0****@gmail.com said:
Richard Heathfield wrote:
It is you who claim that things have changed - that most people now
use C99. The burden of proof is therefore on you. (Saying "it's so"
does not constitute proof.)
That's clearly something nearly impossible to prove.
Yes, it's certainly very difficult to prove something that isn't true.
You don't know whether it's true or not.

"Kid, I've flown from one side of this galaxy to the other, and I've seen a
lot of strange stuff, but I've never seen anyone use a C99
implementation", as Han Solo nearly said. How many horses must you count,
and how many times must you *not* see a unicorn, before you're allowed to
say that unicorns aren't as common as horses?
This obviously nonsense, because there are many C99 implementations.
<snip>
You said
"That's curious, since you don't use C99 yourself"
which I denied.
Let's get this straight, once and for all. Do you use a conforming C99
implementation? If so, which one? (If your answer is "gcc", then no, you
don't use a conforming C99 implementation.)
No.
And I never claimed I did.
I said I used a C99 implementation.

So you are drawing a distinction between "C99 implementation" and
"conforming C99 implementation". I would argue that there is no such
distinction - that an implementation either conforms, or does not conform,
to C99. There is no middle ground.
Everybody uses the terms that way. Doesn't that tell you something?
<snip>
[...] Either you use a conforming C99 implementation or you
don't. Decide.
No.
And I never claimed I did.

Fine. We have now established that you do not use a conforming C99
implementation.
So far so good...
Good. Since an implementation that does not conform to C99
is not a C99 implementation, we have also established that you do not use
a C99 implementation. Good. Finally.
....but not so good. False.
[...] 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.
Do I really need to say anything
else but "False"?

Well, "True" would have been a lot closer to the mark, wouldn't it?

<snip>
It's as simple as this: Not everything is as exact and concise as
mathematics.

Nevertheless, we can say with exactness and concision that implementations
either do, or do not, conform to C99.
Saying "and implementation conforms, but it doesn't" is a null
statement, and I've never said anything like that (and it's not what I
was referring to in that sentence).
<snip>
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.
I don't even know
whether you realise your argument made that assumption. Nevertheless, make
it it did. It's as if we were to suggest that the majority of people drive
Porsches because they are available in both left-hand-drive and
right-hand-drive. But there are other relevant factors! Not everyone can
afford a Porsche (or a C99 implementation).
There are free C99 implementations. I don't know much about compilers,
but so far in this discussion we've mentioned two, one of which was
discussed about two posts ago, remember?
Of those who can, not everyone
likes them. Of those who do, not everyone is in control of the decision to
buy or not buy one. Of those who are, not everyone necessarily wants to
spend the money in that way.
Those three points are equally applicable for an implementation of any
standard.
(Yes, I know Intel C is free - or at least,
I'm prepared to take your word for it - but the point is nevertheless
valid. Not everyone uses a platform supported by Intel.)

<snip>
But I don't want to beg the question myself, so let's look at it another
way. If by some strange chance there is a C programmer out there who
doesn't have a C90 implementation, that programmer is not one of my
users (because he or she is not using my code, because they can't,
because they don't have a C90 implementation). Therefore, all my users
have C90 implementations. :-)
Well if they don't object to you the first time you send them code
they can't compile, it's only logical to assume they do have a C90
implementation. So the bottom line is that it would be equally
acceptable to send them any code: C99, C++, Java! :-) And if they
don't object, then it means it's OK.

Yes, that's a perfectly reasonable point - until, of course, they /do/
object. And that is precisely what would happen if I started littering my
code with C99isms.
Since they don't tell you anything about their systems, that's hard to
know (and, IMO, unlikely to happen).
<snip>
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.htmlmakes it very clear.
Like I already told Keith, they don't mention that there.

Yes, they do, by listing the ways in which their implementation does not
conform to C99.
That doesn't imply the words "we don't have a C99 implementation"
either explicitly or implicitly.

Sebastian

Aug 19 '08 #147
s0****@gmail.com wrote, On 19/08/08 20:27:
On Aug 19, 7:19 am, Richard Heathfield <rj*@see.sig.invalidwrote:
>s0****@gmail.com said:
>>Richard Heathfield wrote:
s0****@gmail.com said:
Richard Heathfield wrote:
>It is you who claim that things have changed - that most people now
>use C99. The burden of proof is therefore on you. (Saying "it's so"
>does not constitute proof.)
That's clearly something nearly impossible to prove.
Yes, it's certainly very difficult to prove something that isn't true.
You don't know whether it's true or not.
"Kid, I've flown from one side of this galaxy to the other, and I've seen a
lot of strange stuff, but I've never seen anyone use a C99
implementation", as Han Solo nearly said. How many horses must you count,
and how many times must you *not* see a unicorn, before you're allowed to
say that unicorns aren't as common as horses?

This obviously nonsense, because there are many C99 implementations.
Name 10. For each one you name others will be able to name 10 C90
implementations. That is even if you use implementations which are
closer to C99 than C90 and the rest of us stick strictly to conforming
implementations of C90. If you stick to only conforming C99
implementations I doubt you will even reach 10.

I know of *one* implementation which comes close (for some value of
close) to C99 and does not have a supported C90 mode that conforms
(modulo bugs) to C90.
>>>>You said
"That's curious, since you don't use C99 yourself"
which I denied.
Let's get this straight, once and for all. Do you use a conforming C99
implementation? If so, which one? (If your answer is "gcc", then no, you
don't use a conforming C99 implementation.)
No.
And I never claimed I did.
I said I used a C99 implementation.
So you are drawing a distinction between "C99 implementation" and
"conforming C99 implementation". I would argue that there is no such
distinction - that an implementation either conforms, or does not conform,
to C99. There is no middle ground.

Everybody uses the terms that way. Doesn't that tell you something?
This is one of the few places where I come across the term C99 and a
significant number of people here mean conforming implementations when
they talk about C99. Personally I would expect people to mention if the
they did *not* mean a conforming implementation.
>>>[...] Either you use a conforming C99 implementation or you
don't. Decide.
No.
And I never claimed I did.
Fine. We have now established that you do not use a conforming C99
implementation.

So far so good...
>Good. Since an implementation that does not conform to C99
is not a C99 implementation, we have also established that you do not use
a C99 implementation. Good. Finally.

...but not so good. False.
So what do you mean by a C99 compiler? Remember that an old pre-ANSI
standard compiler can correctly compile C99 code provided you stick to
the portions of C99 that it supports.
>>[...] 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.

gcc still defaults to using GNU89 which is C89 + extensions (rather than
the incomplete C99 mode, and I suspect that the majority of gcc users
don't override this default.

I've not heard of a rush by embedded compiler developers to implement
C99, so probably most developers for embedded systems still use C90.

There, you now have a reasoned argument as to why most new C development
is in C90 + extensions and *not* in C99 - bits not implemented or broken.
>>Do I really need to say anything
else but "False"?
Well, "True" would have been a lot closer to the mark, wouldn't it?

<snip>
>>It's as simple as this: Not everything is as exact and concise as
mathematics.
Nevertheless, we can say with exactness and concision that implementations
either do, or do not, conform to C99.

Saying "and implementation conforms, but it doesn't" is a null
statement, and I've never said anything like that (and it's not what I
was referring to in that sentence).
You have yet to say where *you* draw the border between a C89 and a C99
implementation.

Note that the reason GNU have not yet switched to GNU99 (C99 +
extensions) being the default for their compiler is that it is not fully
implemented. It also in the info pages when talking about C99 that,
"this standard is not fully supported."
>>>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.
>I don't even know
whether you realise your argument made that assumption. Nevertheless, make
it it did. It's as if we were to suggest that the majority of people drive
Porsches because they are available in both left-hand-drive and
right-hand-drive. But there are other relevant factors! Not everyone can
afford a Porsche (or a C99 implementation).

There are free C99 implementations.
That does not mean that people can use them. Possible reasons for not
using them include:
- Management specifying which compiler to use
- Not being aware of the free implementations
- The non-free implementations being better (in any of a number of ways)
I don't know much about compilers,
but so far in this discussion we've mentioned two, one of which was
discussed about two posts ago, remember?
So? I've probably used 10 times that number of different compilers, and
that is excluding switching to newer versions of a specific compiler.
For about half of my C development career I had little choice about
which compiler to use either because there *was* no alternative or due
to reasons such as those I mention above.
>Of those who can, not everyone
likes them. Of those who do, not everyone is in control of the decision to
buy or not buy one. Of those who are, not everyone necessarily wants to
spend the money in that way.

Those three points are equally applicable for an implementation of any
standard.
It is *extremely* difficult to find compilers that do *not* have a mode
that conforms to C90. I can think of two or three, and NONE of those are
even vaguely approaching C99 (most if not all of what does not conform
to C90 is in the common subset of C90 and C99).
>(Yes, I know Intel C is free - or at least,
I'm prepared to take your word for it - but the point is nevertheless
valid. Not everyone uses a platform supported by Intel.)

<snip>
>>>But I don't want to beg the question myself, so let's look at it another
way. If by some strange chance there is a C programmer out there who
doesn't have a C90 implementation, that programmer is not one of my
users (because he or she is not using my code, because they can't,
because they don't have a C90 implementation). Therefore, all my users
have C90 implementations. :-)
Well if they don't object to you the first time you send them code
they can't compile, it's only logical to assume they do have a C90
implementation. So the bottom line is that it would be equally
acceptable to send them any code: C99, C++, Java! :-) And if they
don't object, then it means it's OK.
Yes, that's a perfectly reasonable point - until, of course, they /do/
object. And that is precisely what would happen if I started littering my
code with C99isms.

Since they don't tell you anything about their systems, that's hard to
know (and, IMO, unlikely to happen).
How much do you know about Richard's typical customers?
>>>>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.htmlmakes it very clear.
Like I already told Keith, they don't mention that there.
Yes, they do, by listing the ways in which their implementation does not
conform to C99.

That doesn't imply the words "we don't have a C99 implementation"
either explicitly or implicitly.
Well, there info page states as the reason for not making gnu99 the
default mode (instead of gnu89) that it is not fully implemented. Since
the extensions GNU provide to C99 are *also* extensions they provide to
C90, it is obviously the implementation of the base C99 language they
consider to be too far from compete for it to be the default mode. That,
to me, *does* imply that they do not consider gcc to have a C99
implementation yet, just something they are working on getting there.
--
Flash Gordon
Aug 19 '08 #148
s0****@gmail.com writes:
[...]
This obviously nonsense, because there are many C99 implementations.
[...]

Not in the sense that the vast majority of us here use the term "C99
implementations".

There are many implementations that implement *most* of the C99
standard. There are a substantial but smaller number of
implementations that implement most of the C99 features that aren't in
C90. There are only a few implementations that *fully* conform to the
C99 standard.

I believe that the above is consistent with what you *meant* when you
said that "there are many C99 implementations".

But most of us here use the unqualified phrase "C99 implementations"
only to refer to *fully conforming* C99 implementations.

If you want to argue that the phrase *should* be applicable to subset
implementations, by all means do so. Instead, you just continue to
assume that it means what you want it to mean and ignore any arguments
to the contrary. It's boring.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 19 '08 #149
On Aug 19, 3:39*pm, Flash Gordon <sp**@flash-gordon.me.ukwrote:
s0****@gmail.com wrote, On 19/08/08 20:27:
On Aug 19, 7:19 am, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@gmail.com said:
>Richard Heathfield wrote:
s0****@gmail.com said:
Richard Heathfield wrote:
It is you who claim that things have changed - that most people now
use C99. The burden of proof is therefore on you. (Saying "it's so"
does not constitute proof.)
That's clearly something nearly impossible to prove.
Yes, it's certainly very difficult to prove something that isn't true.
You don't know whether it's true or not.
"Kid, I've flown from one side of this galaxy to the other, and I've seen a
lot of strange stuff, but I've never seen anyone use a C99
implementation", as Han Solo nearly said. How many horses must you count,
and how many times must you *not* see a unicorn, before you're allowedto
say that unicorns aren't as common as horses?
This obviously nonsense, because there are many C99 implementations.

Name 10. For each one you name others will be able to name 10 C90
implementations. That is even if you use implementations which are
closer to C99 than C90 and the rest of us stick strictly to conforming
implementations of C90. If you stick to only conforming C99
implementations I doubt you will even reach 10.
There are obviously more C90 implementations than there are C99
implementations. What I meant was that, in general, there are many C99
implementations.
I know of *one* implementation which comes close (for some value of
close) to C99 and does not have a supported C90 mode that conforms
(modulo bugs) to C90.
>>>You said
"That's curious, since you don't use C99 yourself"
which I denied.
Let's get this straight, once and for all. Do you use a conforming C99
implementation? If so, which one? (If your answer is "gcc", then no,you
don't use a conforming C99 implementation.)
No.
And I never claimed I did.
I said I used a C99 implementation.
So you are drawing a distinction between "C99 implementation" and
"conforming C99 implementation". I would argue that there is no such
distinction - that an implementation either conforms, or does not conform,
to C99. There is no middle ground.
Everybody uses the terms that way. Doesn't that tell you something?

This is one of the few places where I come across the term C99 and a
significant number of people here mean conforming implementations when
they talk about C99. Personally I would expect people to mention if the
they did *not* mean a conforming implementation.
Sometimes, when it's relevant. But frequently they don't.
>>[...] Either you use a conforming C99 implementation or you
don't. Decide.
No.
And I never claimed I did.
Fine. We have now established that you do not use a conforming C99
implementation.
So far so good...
Good. Since an implementation that does not conform to C99
is not a C99 implementation, we have also established that you do not use
a C99 implementation. Good. Finally.
...but not so good. False.

So what do you mean by a C99 compiler? Remember that an old pre-ANSI
standard compiler can correctly compile C99 code provided you stick to
the portions of C99 that it supports.
Sure, but that isn't usually the case for compilers that claim to
support C99, either conforming or not.
>[...] 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.
gcc still defaults to using GNU89 which is C89 + extensions (rather than
the incomplete C99 mode, and I suspect that the majority of gcc users
don't override this default.
That doesn't mean GCC users don't have access to a C99 implementation.
I've not heard of a rush by embedded compiler developers to implement
C99, so probably most developers for embedded systems still use C90.
Yes, embedded systems is probably one of the places where it'd be more
advantageous to use C90. But that's a very specific case.
There, you now have a reasoned argument as to why most new C development
is in C90 + extensions and *not* in C99 - bits not implemented or broken.
If you're going to use extensions, you're limiting the code to be
compiled only under the compiler that supports those extensions. In
contrast, using C99 would only limit the code to be compiled under a
C99 implementation, which would be more portable than using compiler-
specific extensions.
>Do I really need to say anything
else but "False"?
Well, "True" would have been a lot closer to the mark, wouldn't it?
<snip>
>It's as simple as this: Not everything is as exact and concise as
mathematics.
Nevertheless, we can say with exactness and concision that implementations
either do, or do not, conform to C99.
Saying "and implementation conforms, but it doesn't" is a null
statement, and I've never said anything like that (and it's not what I
was referring to in that sentence).

You have yet to say where *you* draw the border between a C89 and a C99
implementation.

Note that the reason GNU have not yet switched to GNU99 (C99 +
extensions) being the default for their compiler is that it is not fully
implemented. It also in the info pages when talking about C99 that,
"this standard is not fully supported."
>>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.
I don't even know
whether you realise your argument made that assumption. Nevertheless, make
it it did. It's as if we were to suggest that the majority of people drive
Porsches because they are available in both left-hand-drive and
right-hand-drive. But there are other relevant factors! Not everyone can
afford a Porsche (or a C99 implementation).
There are free C99 implementations.

That does not mean that people can use them. Possible reasons for not
using them include:
- Management specifying which compiler to use
That'd be the case for an implementation of any standard.
- Not being aware of the free implementations
Do you think that's a valid excuse? Anyway, that'd also be the case
for an implementation of any standard.
- The non-free implementations being better (in any of a number of ways)
Quite possibly, but that'd also be the case for an implementation of
any standard. Though in this case it might be admittedly more probable
in the case of C99 since it's more recent.
I don't know much about compilers,
but so far in this discussion we've mentioned two, one of which was
discussed about two posts ago, remember?

So? I've probably used 10 times that number of different compilers, and
that is excluding switching to newer versions of a specific compiler.
For about half of my C development career I had little choice about
which compiler to use either because there *was* no alternative or due
to reasons such as those I mention above.
Of those who can, not everyone
likes them. Of those who do, not everyone is in control of the decision to
buy or not buy one. Of those who are, not everyone necessarily wants to
spend the money in that way.
Those three points are equally applicable for an implementation of any
standard.

It is *extremely* difficult to find compilers that do *not* have a mode
that conforms to C90. I can think of two or three, and NONE of those are
even vaguely approaching C99 (most if not all of what does not conform
to C90 is in the common subset of C90 and C99).
What does that have to do with the three points Richard mentioned?
>
(Yes, I know Intel C is free - or at least,
I'm prepared to take your word for it - but the point is nevertheless
valid. Not everyone uses a platform supported by Intel.)
<snip>
>>But I don't want to beg the question myself, so let's look at it another
way. If by some strange chance there is a C programmer out there who
doesn't have a C90 implementation, that programmer is not one of my
users (because he or she is not using my code, because they can't,
because they don't have a C90 implementation). Therefore, all my users
have C90 implementations. :-)
Well if they don't object to you the first time you send them code
they can't compile, it's only logical to assume they do have a C90
implementation. So the bottom line is that it would be equally
acceptable to send them any code: C99, C++, Java! :-) And if they
don't object, then it means it's OK.
Yes, that's a perfectly reasonable point - until, of course, they /do/
object. And that is precisely what would happen if I started litteringmy
code with C99isms.
Since they don't tell you anything about their systems, that's hard to
know (and, IMO, unlikely to happen).

How much do you know about Richard's typical customers?
He told me most of them don't bother to tell him about their system.
Whether they would object to the code he sends because it doesn't work
on their systems depends of course on what kinds of systems they use,
but I think in general most people would be able to accept C99, unlike
he thinks. Of course, these are just wild guesses.
>>>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.htmlmakesit very clear.
Like I already told Keith, they don't mention that there.
Yes, they do, by listing the ways in which their implementation does not
conform to C99.
That doesn't imply the words "we don't have a C99 implementation"
either explicitly or implicitly.

Well, there info page states as the reason for not making gnu99 the
default mode (instead of gnu89) that it is not fully implemented. Since
the extensions GNU provide to C99 are *also* extensions they provide to
C90, it is obviously the implementation of the base C99 language they
consider to be too far from compete for it to be the default mode. That,
to me, *does* imply that they do not consider gcc to have a C99
implementation yet, just something they are working on getting there.
To me, it implies that they consider GCC to have a C90 implementation,
a C99 implementation, and a custom implementation of their own for
each of the two standards. But we've yet got to see what they say.

Sebastian

Aug 19 '08 #150

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.