Scope of a variable declared in for loop

[Keith Thompson]

gwowen a écrit :

The "Piccolo dsp" is not a stand alone processor and must be used with an
ARM7 processor, a product line introduced in 1992, 7 YEARS BEFORE the C
standard was out in 1999. We see here the bad faith of this people when
complaining about C99.

jacob, if someone disagrees with you, please stop for just a moment
and consider the possibility that they might not be deliberately
lying.

 

[Malcolm McLean]

Richard Heathfield a écrit :


Yes. C89 is obsolete and Thompson with it.

My MPI compiler, back in the days when I had a parallel machine, threw
out slash slash comments.

 

[Keith Thompson]

What a sin! Misspelling thompson's name...

My name is spelled with a capital 'T'. I have consistently
respected the way you prefer to spell your own name. Please return
the courtesy.

[snip]

 

[Seebs]

Thanks for the correction. I should have checked C99, but given its
absence from my day-to-day existence, I tend to forget about it.

Fair enough. If someone asked me whether you could do that in C, the
"right" answer, IMHO, is the qualified one. If you MUST give an unqualified
answer, "no" is safer.

-s

 

[Seebs]

gwowen a écrit :

You are talking nonse or just LYING

I cite from
http://www.ghs.com/news/20070131_compiler_version5.html

Can you check something for me in lcc-win?

If I have the code:
if (4 == 5) {
printf("You are talking nonse or just LYING\n");
}

will it usually produce output?

-s

 

[Seebs]

The "Piccolo dsp" is not a stand alone processor and must be used with an
ARM7 processor, a product line introduced in 1992, 7 YEARS BEFORE the C
standard was out in 1999. We see here the bad faith of this people when
complaining about C99.

I don't see how. I mean, we're still compiling for i386...

-s

 

[Seebs]

jacob, if someone disagrees with you, please stop for just a moment
and consider the possibility that they might not be deliberately
lying.

http://work911.com/communication/miller.htm

"To understand what another person is saying, you must assume
that it is true and try to imagine what it could be true of."

This is an extremely effective strategy.

More useful than accusing gwowen of lying would be to observe that what he
said was definitely true *of the compiler he mentioned*, and then ask the
question of whether that compiler is generally relevant. I suspect it
probably is to many people.

Look at it this way: I do compiler support. We're about to take delivery
of a toolchain based on gcc 4.4.x. We are still supporting toolchains based
on gcc 3.4. We will be for some time. It's only relatively recently that a
majority of incoming support requests have involved the 4.x toolchains -- and
4.1.x may still be outnumbering 4.3.x in our world.

-s

 

[jacob navia]

Seebs a écrit :

http://work911.com/communication/miller.htm

"To understand what another person is saying, you must assume
that it is true and try to imagine what it could be true of."

This is an extremely effective strategy.

More useful than accusing gwowen of lying would be to observe that what he
said was definitely true *of the compiler he mentioned*, and then ask the
question of whether that compiler is generally relevant. I suspect it
probably is to many people.

He did not say that the version is many years old and that a newer version
with C99 support is available. Just said "Green Hills compiler so and so
doesn't use C99'. To people that do not know the context, this means that
"Green Hills doesn't support C99".

Obviously he is in good company since heathfield uses a very ancient version
of gcc, and then says "my gcc doesn't compile this stuff", without mentioning
that his version is at least a decade old...

THEN

.... he is not lying (of course). He just said that his version of gcc
doesn't compile that stuff...

All those lame justifications can't hide the fact that he should have known
that a newer version of his compiler suite is available, and that he did NOT
tell us that fact.

Look at it this way: I do compiler support. We're about to take delivery
of a toolchain based on gcc 4.4.x. We are still supporting toolchains based
on gcc 3.4. We will be for some time. It's only relatively recently that a
majority of incoming support requests have involved the 4.x toolchains -- and
4.1.x may still be outnumbering 4.3.x in our world.

-s

And what you would think if a guy told you

YOU do not support feature XYZ

because my version of 10 years ago doesn't have it?

Wouldn't you tell him "UPGRADE" ???

And if he would say that in a public forum would you accept that?

Look Seebs, for you heathfield is always right and i am always wrong.
Be it. You have won your honor place in the hierarchy of clc "regs"...

 

[William Hughes]

And now you are telling us that "there is no C99 support" in Green Hills
compilers?

Please do not deliberately misquote. Even
if you think your paraphrase is accurate it is
a lie to present it as a quote.

(Please do not argue that your paraphrase was
accurate. Note the "Even if")

- William Hughes

 

[Ian Collins]

There is only ONE fully conforming C++ 1998 implementation, 12 years
after that standard was printed.

So what?

C++98 is a "failed language"?

Oh come on, not that old chestnut again. All modern C++ compilers
strive to comply with the standard, with the exception of the "export"
keyword. That's a lot different form refusing to implement a standard.

But saying that, like others who correct you, you will ignore me.

 

[Ben Bacarisse]

Stroustrup mentions declarations in conditions in the 1994 edition of
"The Design and Evolution of C++". It's probably also in the 2nd
edition of The C++ Programming Language, but I don't have my copy
handy.

I happen to have one here and, no it is not in there yet. Mind you,
the 2nd edition I have is 1991 so rather hard on the heels of the ARM
for a major change. 1991-1994 seems to be the window, then.

 

[Seebs]

He did not say that the version is many years old and that a newer version
with C99 support is available.

He may not have known it. I still don't actually know it, because I haven't
got detailed technical information to explain the context and meaning of
the marketing claim.

Just said "Green Hills compiler so and so
doesn't use C99'. To people that do not know the context, this means that
"Green Hills doesn't support C99".

It doesn't to me. All it tells me is that a specific version, which is in
use by at least one person, doesn't.

... he is not lying (of course). He just said that his version of gcc
doesn't compile that stuff...
Right.

All those lame justifications can't hide the fact that he should have known
that a newer version of his compiler suite is available, and that he did NOT
tell us that fact.

Why should he have known that? I don't have any idea whether gcc is currently
on 4.4 or 4.5, nor do I know whether either of them addresses any of the
remaining gaps in C99 support. Why should I care? It's not going to affect
me for months or years, if at all.

And what you would think if a guy told you
YOU do not support feature XYZ
because my version of 10 years ago doesn't have it?
Wouldn't you tell him "UPGRADE" ???

Yup. I do that all the time.

And if he would say that in a public forum would you accept that?

If he said "Wind River Linux 1.4 doesn't support...", I might point out that
3.0 does, but I wouldn't accuse him of lying.

Look Seebs, for you heathfield is always right and i am always wrong.

Not particularly. I think he's wrong about camel case, for instance. And
I think you're quite often right. I don't even dispute that, in general, I
think most people could probably reasonably decide to rely on a large number
of C99 features these days, and justifiably expect that their code would
find a reasonable number of compilers that would handle it. I just think
that it is unreasonable to accuse someone of lying when what he said is
clearly completely true, and your counterargument is a poorly-worded bit of
marketing fluff.

I do not at this time know of a single 100% compliant and validated C99
compiler. Maybe there are some. I neither know nor particularly care.

-s

 

[Seebs]

Seebs wrote:

There are several. See http://www.peren.com/pages/cvsa_isocvpl.htm

Hmm. Interesting; I'm not totally surprised that both IBM and Sun have
them. They're sort of out of my regular stomping grounds, though.

-s

 

[Rob Kendrick]

There is gcc for ARM, which supports C99.

Sure, but how does this help you compile C99 for the Piccolo DSP?

B.

 

[Nick]

Yeah, I know. C99 is the de jure standard, and C90 is de jure
obsolete. But just about every C compiler vendor supports C90, but
only a small handful support C99. So C90 is the de facto standard.

It feels to me, though, that there is a de facto "standard" version of C
that is C90 plus a lot of C99 features without being full C99.

Something like - at least - C90 plus // plus VLAs plus mixed
declarations and code plus declarations in the first clause of for.

You do sometimes take a position that because there are no C99
compilers, code using any of these isn't "proper" C. It seems to me
that if you have code that is valid under the most recent standard /and/
is compilable correctly by a signficant number of main-stream and
popular compilers, there's nowt wrong with calling it standard C.

None of this excuses Jacob's foaming at the mouth that anyone who
doesn't fill their code with complex types is obsolete, of course.

Code written to either standard is topical here, so it's a rather
silly dispute. The decision about whether to use C90-only features, or
C99-only features, or neither, is a trade-off decision best made by
the development team leader, not by capital letters on Usenet.

And yet whenever anyone posts code here using only features in that
common subset of C99 features that I mentioned, someone does seem to
leap up and say "don't do that because there are no C99 compilers".

 

[Keith Thompson]

It feels to me, though, that there is a de facto "standard" version of C
that is C90 plus a lot of C99 features without being full C99.

Something like - at least - C90 plus // plus VLAs plus mixed
declarations and code plus declarations in the first clause of for.

Perhaps, but I don't think there's enough agreement on *which* subset
of C99-specific features to include for this to be called a de facto
standard.

You do sometimes take a position that because there are no C99
compilers, code using any of these isn't "proper" C. It seems to me
that if you have code that is valid under the most recent standard /and/
is compilable correctly by a signficant number of main-stream and
popular compilers, there's nowt wrong with calling it standard C.

First of all, there *are* C99 compilers, and I think anyone claims
otherwise. I don't recall seeing Richard Heathfield (or anyone else)
saying that such code isn't "proper" C. I've merely seen him and
others (including myself) remind people that code with C99-specific
constructs are not quite as portable as pure C90. Can you provide a
citation?

Yes, code that uses C99-specific features while conforming to the C99
standard is standard C.

None of this excuses Jacob's foaming at the mouth that anyone who
doesn't fill their code with complex types is obsolete, of course.


And yet whenever anyone posts code here using only features in that
common subset of C99 features that I mentioned, someone does seem to
leap up and say "don't do that because there are no C99 compilers".

I think that's an exaggeration (or misunderstanding) of the actual
reaction, which is that programmers should *consider* whether the
advantages of C99-specific features are enough to override the loss of
portability. (Sometimes the answer is yes.)

A lot of what might seem like anti-C99 comments are actually reactions
to the apparent attitude that one shouldn't even consider that C99
might be non-portable.

 

[Keith Thompson]

You do sometimes take a position that because there are no C99
compilers, code using any of these isn't "proper" C.

[...]

First of all, there *are* C99 compilers, and I think anyone claims
otherwise.

Correction: I *don't* think anyone claims otherwise.