Scope of a variable declared in for loop
vaysagekv
A)Is it possible to declare a variable inside for loop like
for(int i=100;i>=0;i--);
if yes what is the scope of that variable?
B)if there is a for loop like below
for(int i=0;int c = getchar();i++);
after finishing for loop execution c variable will be destroyed or not.
Richard Heathfield
> Hi,
> A)Is it possible to declare a variable inside for loop like
> for(int i=100;i>=0;i--);
In C90, no. Compilers are free to provide it as an extension., but you
can't rely on its provision.
In C99, yes, it's possible.
> if yes what is the scope of that variable?
The loop control, and the statement that follows it (which may of course
be a block statement).
> B)if there is a for loop like below
>
> for(int i=0;int c = getchar();i++);
>
> after finishing for loop execution c variable will be destroyed or not.
Without actually looking it up in the Standard, I won't be 100%
dogmatic, but I'm pretty darn sure it's a syntax error. You can define
an object in the initialisation part of the for() control structure, but
I'm almost certain you can't do so in the test or mod parts.
(Actually, I'm completely certain. But I've been completely certain
before and turned out to be wrong, which is why I'm hedging.)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Malcolm McLean
people use C++ as what is to all intents and purposes a C compiler
with a few differences, one being that C++ always allows variables to
be declared anywhere.
Mark Bluemel
> Hi,
> A)Is it possible to declare a variable inside for loop like
> for(int i=100;i>=0;i--);
Not in C.
Variables can be declared inside a block (i.e. between braces) but not
in the context you are talking about.
> if yes what is the scope of that variable?
The question does not arise.
Alexander Bartolich
> [...]
> A)Is it possible to declare a variable inside for loop like
> for(int i=100;i>=0;i--);
You can do this in C99 and C++, but not in preceding C standards.
Given the low popularity of C99 amongst compiler vendors I recommend
against using its features.
> if yes what is the scope of that variable?
According to the standard (both C99 and C++) the scope is restricted to
the loop, i.e. variable »i« is not visible outside the loop. However,
some older C++ compilers did this wrong. Some contemporary compilers
provide an option to switch scoping to the non-standard behaviour.
> B)if there is a for loop like below
>
> for(int i=0;int c = getchar();i++);
This code violates the standard. Variable declarations are allowed
only in the first clause of the for-statement, i.e. like this:
for(int c, i = 0; c = getchar(); i++);
> after finishing for loop execution c variable will be destroyed or not.
The standard only regulates the scope of the variable.
Whether the memory required by block-local variables is reclaimed at
the end of the block or at the end of the enclosing function is up to
the implementation.
--
santosh
> On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
>> Hi,
>> A)Is it possible to declare a variable inside for loop like
>> for(int i=100;i>=0;i--);
>
> Not in C.
>
> Variables can be declared inside a block (i.e. between braces) but
> not in the context you are talking about.
I'm sure it's just a case of over-looking, but just for lurkers'
benefit, the first code snippet shown by the OP, which you've quoted
above is correct C, though "C99 only", one should qualify.
The second of his for loops is a syntax I believe, since declarations
are only allowed in the initialisation part of the for loop, AFAIK.
>> if yes what is the scope of that variable?
>
> The question does not arise.
For the first example, it does arise.
Richard Heathfield
> On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
>> Hi,
>> A)Is it possible to declare a variable inside for loop like
>> for(int i=100;i>=0;i--);
>
> Not in C.
FCVO C. In C99, it's fine.
<snip>
Seebs
> Hi,
> A)Is it possible to declare a variable inside for loop like
> for(int i=100;i>=0;i--);
In C99, yes. In C89, no.
> if yes what is the scope of that variable?
The loop.
> B)if there is a for loop like below
>
> for(int i=0;int c = getchar();i++);
>
> after finishing for loop execution c variable will be destroyed or not.
I'm not sure that's allowed off the top of my head -- I thought only the first
clause could be a declaration. But in any event, yes, the variable's scope is
the loop only.
I believe this is now true in C++. I have a published book in which it's
explained that it should have been true, but that there was so much existing
code relying on access to the loop variable after the loop that it could never
be done. :)
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Phred Phungus
> On 2010-02-23, vaysagekv <kvva...@gmail.com> wrote:
>> Hi,
>> A)Is it possible to declare a variable inside for loop like
>> for(int i=100;i>=0;i--);
>
> In C99, yes. In C89, no.
>
>> if yes what is the scope of that variable?
>
> The loop.
>
>> B)if there is a for loop like below
>>
>> for(int i=0;int c = getchar();i++);
>>
>> after finishing for loop execution c variable will be destroyed or not.
>
> I'm not sure that's allowed off the top of my head -- I thought only the first
> clause could be a declaration. But in any event, yes, the variable's scope is
> the loop only.
>
> I believe this is now true in C++. I have a published book in which it's
> explained that it should have been true, but that there was so much existing
> code relying on access to the loop variable after the loop that it could never
> be done. :)
>
> -s
Which book?
--
fred
Seebs
> Which book?
If I remembered, I'd have said. It was probably one of the early editions
of design & evolution of C++ or something similar.
Keith Thompson
> On 2010-02-23, Phred Phungus <Ph...@example.invalid> wrote:
>> Which book?
>
> If I remembered, I'd have said. It was probably one of the early editions
> of design & evolution of C++ or something similar.
In the 1994 edition of "The Design and Evolution of C++", Stroustrup
says:
Unfortunately, I didn't take the opportunity to change the
semantics to limit the scope of a variable introduced in this
way to the scope of the for-statement. The reason for this
omission was primarily to avoid adding a special case to the
rule that says "the scope of a variable extends from the point
of its declaration to the end of its block".
This rule is the subject of much discussion and may be revised
to match the rule for declarations in conditions.
It was revised in this way, apparently before C99 picked up the
feature. (Declarations in conditions are another C++ feature that
C99 didn't adopt.)
--
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"
Seebs
> It was revised in this way, apparently before C99 picked up the
> feature. (Declarations in conditions are another C++ feature that
> C99 didn't adopt.)
In the C99 discussion, we weren't sure which way C++ went, but we
decided to just do the scope correctly regardless, as I recall.
Happily, this turned out not to be an incompatibility.
jacob navia
You are completely wrong. Standard C allows that declaration and the scope
is the scope of the for block.
Read the standard before answering please
jacob navia
> vaysagekv wrote:
>> [...]
>> A)Is it possible to declare a variable inside for loop like
>> for(int i=100;i>=0;i--);
>
> You can do this in C99 and C++, but not in preceding C standards.
> Given the low popularity of C99 amongst compiler vendors I recommend
> against using its features.
>
Standard C is implemented in most systems. This person is just talking nonsense
Richard Heathfield
Well, C90 is. I would suggest that C99 has yet to justify so bold a claim.
> This person is just talking nonsense
No, he's talking common sense. You, on the other hand, are talking
emotive crap. Why do you get so worked up about it?
Richard
> On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
>> Hi,
>> A)Is it possible to declare a variable inside for loop like
>> for(int i=100;i>=0;i--);
>
> Not in C.
Huh? What C do you use?
Not only can you, its recommended.
>
> Variables can be declared inside a block (i.e. between braces) but not
> in the context you are talking about.
>
>> if yes what is the scope of that variable?
>
> The question does not arise.
I'm afraid it does.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Keith Thompson
There are plenty of compilers that don't implement, or don't fully
implement, the C99 standard. Support for the C90 standard, on the
other hand, is almost universal.
On the other hand, there are also plenty of compilers that do support
some C99 features, and declarations in for statements are probably
one of the most common implemented features (behind // comments,
I'd guess).
You'll need to decide for yourself whether using C99-specific
features is worth the (perhaps small) loss of portability.
The situation is not as simple as jacob claims it is -- or as both
jacob and I wish it were.
Seebs
> Alexander Bartolich a �crit :
>> You can do this in C99 and C++, but not in preceding C standards.
>> Given the low popularity of C99 amongst compiler vendors I recommend
>> against using its features.
> Standard C is implemented in most systems. This person is just talking
> nonsense
Off the top of my head, I cannot name a single complete implementation.
On the other hand, I don't think I've used any compiler this millennium which
doesn't support declarations in for loops. It's an especially likely feature
simply because so many C compilers are bundled with C++ compilers, meaning
the developer has almost certainly solved this problem.
Kenny McCormack
Richard <rgr...@gmail.com> wrote:
>Mark Bluemel <mark.b...@googlemail.com> writes:
>
>> On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
>>> Hi,
>>> A)Is it possible to declare a variable inside for loop like
>>> for(int i=100;i>=0;i--);
>>
>> Not in C.
>
>Huh? What C do you use?
>
>Not only can you, its recommended.
In the religion of comp.lang.c, nothing exists past C89.
Therefore, it (the declarations which are the subject of this thread)
does not exist.
lovecrea...@gmail.com
> There are plenty of compilers that don't implement, or don't fully
> implement, the C99 standard.
>
People are busy making new C standard while the old one arent' fully
implemented. What will the new one do - withdraw some odd features in
the old one?
Nick Keighley
wrote:
> On Feb 23, 3:35 pm, vaysagekv <kvvays...@gmail.com> wrote:
> > A)Is it possible to declare a variable inside for loop like
> > for(int i=100;i>=0;i--);
>
> > if yes what is the scope of that variable?
>
> > B)if there is a for loop like below
>
> > for(int i=0;int c = getchar();i++);
>
> > after finishing for loop execution c variable will be destroyed or not.
>
> The answers depend on what version of C you are using.
ie. if you the C you are using complies with 1989/90 standard (so-
called C89) or the 1999 standard (so-called C99). C99 supports A).
Noboddy supports option B)!
> Also some
> people use C++ as what is to all intents and purposes a C compiler
> with a few differences,
I'm not sure what this is supposed to mean. C99 and C++ have identical
behaviour as regards defining variables in for loops.
>one being that C++ always allows variables to
> be declared anywhere.
well, no. C++ doesn't support option B) either.
To the OP use Richard Heathfield's reply rather than Malcolm's.
Nick Keighley
wrote:
> vaysagekv wrote:
> > A)Is it possible to declare a variable inside for loop like
> > for(int i=100;i>=0;i--);
[...]
> > if yes what is the scope of that variable?
>
> According to the standard (both C99 and C++) the scope is restricted to
> the loop, i.e. variable »i« is not visible outside the loop. However,
> some older C++ compilers did this wrong. Some contemporary compilers
> provide an option to switch scoping to the non-standard behaviour.
you sure they were actually wrong? I thought the definition of C++
changed. C++ wasn't actually standardised at the time, but was defined
by Stroustrup's book.
santosh
As I understand from previous discussions here and in c.s.c, a
feature has to first be deprecated, before it can be removed.
AFAIK, gets will no longer be present in the next C standard, but
I've no idea about other withdrawals, if any.
What's interesting is that it's going to have support for concurrent
programming. For more discussions, better post in c.s.c.
Michael Tsang
Hash: SHA1
Kenny McCormack wrote:
C99 is not C?! READ THE STANDARD!
According to the standard:
This second edition cancels and replaces the first edition, ISO/IEC
9899:1990, as
amended and corrected by ISO/IEC 9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and
ISO/IEC 9899/COR2:1996. Major changes from the previous edition include:
That is, C99 is the ONLY standard NOW. The previous version has been
replaced by this version. If a C compiler does not fully implement this
standard, then it is not a fully-compliant C compiler.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkuE4l0ACgkQm4klUUKw07DVuQCfVcWTj8FIjvnwvDuWk3TzGNR7
kVAAn3fRpg7e23W0Jm7Ub7abiRkFXaxD
=ctIT
-----END PGP SIGNATURE-----
gwowen
wrote:
> you sure they were actually wrong? I thought the definition of C++
> changed. C++ wasn't actually standardised at the time, but was defined
> by Stroustrup's book.
Correct (though the "Stroustrop's book" in this context isn't D&E,
which is being discussed else-thread.) Standard C++ has always been
"scope is just the loop", but pre-standard C++ -- that described in
The C++ Programming Language 2nd Ed, it lasts till the end of the
inner block in which the for() lives (r6.5.3).
for(init;exp1;exp2)
statement;
used to be equivalent to
init;
while(exp1){
statement;
exp2;
}
Now its equivalent to
{
init;
while(exp1){
statement;
exp2;
}
}
Some compilers (e.g. g++ ) implement both with a switch to select
between them (-ffor-scope)
Mark Bluemel
> Mark Bluemel <mark.blue...@googlemail.com> writes:
> > On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
> >> Hi,
> >> A)Is it possible to declare a variable inside for loop like
> >> for(int i=100;i>=0;i--);
>
> > Not in C.
>
> > Variables can be declared inside a block (i.e. between braces) but
> > not in the context you are talking about.
>
> I'm sure it's just a case of over-looking, but just for lurkers'
> benefit, the first code snippet shown by the OP, which you've quoted
> above is correct C, though "C99 only", one should qualify.
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.
Keith Thompson
Chris Hills, who is a member of the committee, has stated here
that C1X is likely to drop a number of C99 features, for example
in Message-ID: <+UTJjlIs...@phaedsys.demon.co.uk>.
I've seen no confirmation of this from anyone
else, and the C201X committee drafts (the latest is
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1425.pdf>) have
shown no signs of such an effort; they're based on the C99 standard
with clarifications and new features (including threading).
Personally, I think dropping C99-specific features from C201X would
be a bad idea. Though C99 as a whole isn't as widely available
as I'd like, there are *some* conforming or nearly conforming
implementations, and there's code that depends on the new features.
Breaking existing code is not absolutely prohibited, but it's
something the committee has gone to great lengths to avoid.
Keith Thompson
> Kenny McCormack wrote:
[the usual]
>
> C99 is not C?! READ THE STANDARD!
> According to the standard:
Don't worry about what Kenny says. He's lying.
santosh
>> In the religion of comp.lang.c, nothing exists past C89.
>>
>> Therefore, it (the declarations which are the subject of this
>> thread) does not exist.
>
> C99 is not C?! READ THE STANDARD!
> According to the standard:
>
> This second edition cancels and replaces the first edition, ISO/IEC
> 9899:1990, as amended and corrected by ISO/IEC 9899/COR1:1994,
> ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996. Major changes
> from the previous edition include:
>
> That is, C99 is the ONLY standard NOW. The previous version has
> been replaced by this version. If a C compiler does not fully
> implement this standard, then it is not a fully-compliant C
> compiler.
Strictly speaking, I guess you're right. But real world is "fuzzier."
A Standard's aim and reason for coming into existence is to get
widely, if not unanimously, implemented. Otherwise it can be regarded
as not having achieved it's purpose. Implementations always have the
final say, since it's they which ultimately get the job done, not the
standards.
Arguably, the large portion of the reason for why Standard C has not
been widely implemented has to be borne by the ISO committee, for
standardising features lacking broad consensus across atleast most
implementations out there. This was I guess the key difference from
the C90 standardisation.
Let's hope the upcoming standard meets with better success than
C99:-)
And Kenny was being sarcastic there. He full well knows that C99 is
the current C Standard.
jacob navia
> Michael Tsang <mik...@gmail.com> writes:
>> Kenny McCormack wrote:
> [the usual]
>> C99 is not C?! READ THE STANDARD!
>> According to the standard:
> [snip]
>
> Don't worry about what Kenny says. He's lying.
>
He thinks anybody that doesn't agree with the C89 clique here
is lying...
jacob navia
>
> 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.
Please abstain from answering nonsense then. Check if you know the
answer, THEN answer.
Thanks in advance.
Richard
> Mark Bluemel a écrit :
I cant remember the time I last used a C compiler that didn't support
such declarations.
But then I dont pretend, like Messrs Heathfield and his clan, that my C
code is being ported to some valve based mainframe somewhere in deepest
Elbonia.
I also note, with some distaste, that Heathfield and his clan have now
reduced this group to a bitch session by constantly arguing with this
spinoza character who clearly has the knives out for our resident know
all and bible basher.
The general nastiness and smugness that certain regs exude here is a
rarety in technical groups. So hats off to the clique for managing it.
gwowen
> I cant remember the time I last used a C compiler that didn't support
> such declarations.
Green Hills compiler 424 for ARM9 does not support that extension.
TI's compiler for their Piccolo DSP does not support that extension.
I use both of these these frequently. These compilers are not for
outmoded valve powered mainframes -- ARM9's are pretty much the most
ubiquitous microprocessors in the world. You probably have one or two
about your immediate person.
Do you ever write code for non-desktop machines?
Ben Bacarisse
> On 23 Feb, 16:00, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>> On Feb 23, 3:35 pm, vaysagekv <kvvays...@gmail.com> wrote:
<snip>
>> > B)if there is a for loop like below
>>
>> > for(int i=0;int c = getchar();i++);
<snip>
>> Also some
>> people use C++ as what is to all intents and purposes a C compiler
>> with a few differences,
>
> I'm not sure what this is supposed to mean. C99 and C++ have identical
> behaviour as regards defining variables in for loops.
>
>>one being that C++ always allows variables to
>> be declared anywhere.
>
> well, no. C++ doesn't support option B) either.
Sorry but it does. It's off topic so I won't give you all the
quotations but C++ permits a declaration in the condition part of an
'if', 'while', 'for' or 'switch' (but not 'do' of course).
--
Ben.
Richard
Frequently.
But like I said I rarely if ever port to machines that dont support
something as widely used as, say gcc.
The main point remains : its a nice construct and recommended. The more
local a variable declaration the better for all concerned, especially
when dealing with things like loop variables where the end of the loop
means the end of our interest in it.
jacob navia
You are talking nonse or just LYING
I cite from
http://www.ghs.com/news/20070131_compiler_version5.html
that is the official site of Green Hills Software:
Standards and Reliability
The Green Hills compiler was the first compiler for embedded systems to achieve 100% conformance to
ANSI/ISO standards for C and C++. In addition, the new compiler supports the latest C99
specification and the latest MISRA C standard. The Green Hills compilers are tested against industry
standard validation suites, including Plum Hall, and are also tested against the industry�s most
proven and extensive regression test suite.
That version was out in 2007!!!!
And now you are telling us that "there is no C99 support" in Green Hills
compilers?
jacob navia
> TI's compiler for their Piccolo DSP does not support that extension.
>
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.
Kenny McCormack
Michael Tsang <mik...@gmail.com> wrote:
...
>That is, C99 is the ONLY standard NOW. The previous version has been
>replaced by this version. If a C compiler does not fully implement this
>standard, then it is not a fully-compliant C compiler.
ITA (Yes, as others have pointed out, my original post was somewhat
satirical [of the CLC regs])
But the point is that that (what you write above) is *not* the official
dogma of CLC. The official dogma of CLC, as enunciated by leader
Heathfield, is that nothing exists beyond C89. This is further
enunciated by, among others, subordinate Gowen (see his "Green Hills
supports nothing beyond C89" threads).
HTH
Rob Kendrick
jacob navia <ja...@nospam.org> wrote:
> gwowen a écrit :
ARM7 was certainly 1992, but Piccolo? I don't think so. And what is
one meant to use to compile C for running on the DSP part? An ARM
compiler?
B.
Richard Heathfield
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kenny McCormack wrote:
>
>> In article <ko2e57-...@news.eternal-september.org>,
>> Richard <rgr...@gmail.com> wrote:
>>> Mark Bluemel <mark.b...@googlemail.com> writes:
>>>
>>>> On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
>>>>> Hi,
>>>>> A)Is it possible to declare a variable inside for loop like
>>>>> for(int i=100;i>=0;i--);
>>>> Not in C.
>>> Huh? What C do you use?
>>>
>>> Not only can you, its recommended.
>> In the religion of comp.lang.c, nothing exists past C89.
>>
>> Therefore, it (the declarations which are the subject of this thread)
>> does not exist.
>
> C99 is not C?! READ THE STANDARD!
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.
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.
Richard Heathfield
It would be lame to flame you for your spelling error, but it is common
courtesy to get people's names right even if the rest of your spelling
is shot all to pieces.
To call Keith Thompson "obsolete" is to introduce a belligerent tone
into what ought to be a technical issue.
I doubt whether *anyone* here disputes that C99 is the de jure Standard.
Anyone who pretends it's the de facto Standard needs to take a long hard
look out there in the Real World, where only a very small percentage of
C programmers actually use a 100% conforming C99 implementation.
Nick Keighley
Malcolm McLean
>
> The main point remains : its a nice construct and recommended. The more
> local a variable declaration the better for all concerned, especially
> when dealing with things like loop variables where the end of the loop
> means the end of our interest in it.
>
number of levels a human being can keep in mind at any one time.
I think this is an example of the "rule of three" (three levels of
parentheses, three indirections, three dimensions), though I might be
persuaded that in fact it is the rule of five (five layers in a tree
or graph). Certainly you can't have arbitrary levels of scope.
We've already got global globals and file scope globals. Function
scope locals make three. I don't think we want any more.
santosh
Isn't it just a special case of block scope, as is function scope
itself?
I agree that it's a nice convenience, but it can be easily done
without. If functions aren't overly long, it's pretty simple to
declare and use a single, or few, counters throughout the function.
jacob navia
> jacob navia wrote:
>> Keith Thompson a �crit :
>>> Michael Tsang <mik...@gmail.com> writes:
>>>> Kenny McCormack wrote:
>>> [the usual]
>>>> C99 is not C?! READ THE STANDARD!
>>>> According to the standard:
>>> [snip]
>>>
>>> Don't worry about what Kenny says. He's lying.
>>>
>> Don't worry about Thomson, he is just obsolete.
>> He thinks anybody that doesn't agree with the C89 clique here
>> is lying...
>
> It would be lame to flame you for your spelling error, but it is common
> courtesy to get people's names right even if the rest of your spelling
> is shot all to pieces.
>
Well, I did not call him a jerk, as he did to me some time ago.
What a sin! Misspelling thompson's name...
> To call Keith Thompson "obsolete" is to introduce a belligerent tone
> into what ought to be a technical issue.
>
Yes. C89 is obsolete and Thompson with it.
> I doubt whether *anyone* here disputes that C99 is the de jure Standard.
> Anyone who pretends it's the de facto Standard needs to take a long hard
> look out there in the Real World, where only a very small percentage of
> C programmers actually use a 100% conforming C99 implementation.
>
There is only ONE fully conforming C++ 1998 implementation, 12 years
after that standard was printed.
So what?
C++98 is a "failed language"?
You and thompson go on diffusing misinformation. If you stay
with an obsolete standard you are obsolete. Period.
Richard Heathfield
> Richard Heathfield a �crit :
>> jacob navia wrote:
>>> Keith Thompson a �crit :
>>>> Michael Tsang <mik...@gmail.com> writes:
>>>>> Kenny McCormack wrote:
>>>> [the usual]
>>>>> C99 is not C?! READ THE STANDARD!
>>>>> According to the standard:
>>>> [snip]
>>>>
>>>> Don't worry about what Kenny says. He's lying.
>>>>
>>> Don't worry about Thomson, he is just obsolete.
>>> He thinks anybody that doesn't agree with the C89 clique here
>>> is lying...
>>
>> It would be lame to flame you for your spelling error, but it is
>> common courtesy to get people's names right even if the rest of your
>> spelling is shot all to pieces.
>>
>
> Well, I did not call him a jerk, as he did to me some time ago.
If you don't want to be called a jerk by bright people, don't behave
like one.
> What a sin! Misspelling thompson's name...
It's not a sin, but it is a discourtesy.
>
>> To call Keith Thompson "obsolete" is to introduce a belligerent tone
>> into what ought to be a technical issue.
>>
>
> Yes. C89 is obsolete
And yet it is widely (almost universally) implemented, and widely used.
> and Thompson with it.
You do yourself no favours by reducing a technical discussion to a
personality clash.
>> I doubt whether *anyone* here disputes that C99 is the de jure
>> Standard. Anyone who pretends it's the de facto Standard needs to take
>> a long hard look out there in the Real World, where only a very small
>> percentage of C programmers actually use a 100% conforming C99
>> implementation.
>
> There is only ONE fully conforming C++ 1998 implementation, 12 years
> after that standard was printed.
>
> So what?
>
> C++98 is a "failed language"?
Well, clearly it *has* failed to win hearts and minds over the "export"
feature. Nevertheless, AFAIAA C++98 (sans export) is the de facto C++
standard, and so it might be regarded as a resounding success.
> You and thompson go on diffusing misinformation. If you stay
> with an obsolete standard you are obsolete. Period.
You have just dismissed as obsolete a very, very large number of C
programmers. Let us hope for your sake that they don't hold that against
you when deciding which compiler to use on their next project.
Keith Thompson
> jacob navia wrote:
>>> Michael Tsang <mik...@gmail.com> writes:
>>>> Kenny McCormack wrote:
>>> [the usual]
>>>> C99 is not C?! READ THE STANDARD!
>>>> According to the standard:
>>> [snip]
>>>
>>> Don't worry about what Kenny says. He's lying.
>>>
>> Don't worry about Thomson, he is just obsolete.
>> He thinks anybody that doesn't agree with the C89 clique here
>> is lying...
>
> It would be lame to flame you for your spelling error, but it is
> common courtesy to get people's names right even if the rest of your
> spelling is shot all to pieces.
>
> To call Keith Thompson "obsolete" is to introduce a belligerent tone
> into what ought to be a technical issue.
To be fair, I introduced a belligerent tone myself when I called Kenny
a liar.
Though this doesn't justify jacob's latest insult against me.
[...]
Ben Bacarisse
> On 24 Feb, 12:16, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> ... It's off topic so I won't give you all the
>> quotations but C++ permits a declaration in the condition part of an
>> 'if', 'while', 'for' or 'switch' (but not 'do' of course).
>
> ah, thanks. How recent is that?
It's not in The Annotated Reference Manual of 1990 but it is in the
C++ 1998 standard.
--
Ben.
Keith Thompson
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.
ObC: C99 picked up declarations in for statements (with the better
scoping rule that C++ eventually adopted), but not declarations in
conditions.
Keith Thompson
> gwowen a écrit :
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 :
>
> > To call Keith Thompson "obsolete" is to introduce a belligerent tone
> > into what ought to be a technical issue.
>
> Yes. C89 is obsolete and Thompson with it.
>
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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Seebs
> gwowen a �crit :
>> Green Hills compiler 424 for ARM9 does not support that extension.
> 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?
Seebs
> 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...
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.
jacob navia
> On 2010-02-24, Keith Thompson <ks...@mib.org> wrote:
>> 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.
>
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.
--
Ian Collins
Richard Heathfield
<snip>
> 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...
That's partly because it isn't (quite) that old. The release date for my
version of gcc is 2001.
<snip>
> Look Seebs, for you heathfield is always right and i am always wrong.
I'm reasonably sure that isn't true.
> Be it. You have won your honor place in the hierarchy of clc "regs"...
Seebs earned his clc respect long before I joined this group. He did not
do so by flinging random accusations of lying at anyone who disagreed
with him.
Ben Bacarisse
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.
--
Ben.
Seebs
> 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.
Richard Heathfield
<snip>
> 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.
There are several. See http://www.peren.com/pages/cvsa_isocvpl.htm
Seebs
> Seebs wrote:
><snip>
>> 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.
> 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.
Branimir Maksimovic
> On Wed, 24 Feb 2010 13:51:44 +0100
> jacob navia <ja...@nospam.org> wrote:
>
>> gwowen a �crit :
>>> TI's compiler for their Piccolo DSP does not support that extension.
>>>
>> 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.
>
> one meant to use to compile C for running on the DSP part? An ARM
> compiler?
>
> B.
>
There is gcc for ARM, which supports C99.
Greets
Rob Kendrick
Branimir Maksimovic <bm...@hotmail.com> wrote:
> Rob Kendrick wrote:
> > On Wed, 24 Feb 2010 13:51:44 +0100
> > jacob navia <ja...@nospam.org> wrote:
> >
> >> gwowen a écrit :
> >>> TI's compiler for their Piccolo DSP does not support that
> >>> extension.
> >>>
> >> 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.
> >
> > ARM7 was certainly 1992, but Piccolo? I don't think so. And what
> > is one meant to use to compile C for running on the DSP part? An
> > ARM compiler?
> >
>
> There is gcc for ARM, which supports C99.
Sure, but how does this help you compile C99 for the Piccolo DSP?
B.
Branimir Maksimovic
I wrote first usable c++ program in 1997.
All in all c++ programs weren;t portable to different c++ compilers,
especially templates.
Greets
Branimir Maksimovic
>>> TI's compiler for their Piccolo DSP does not support that extension.
>> 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.
>
No one is 100% correct and 100% error proof.
Greets
Branimir Maksimovic
>>>
>> There is gcc for ARM, which supports C99.
>
> Sure, but how does this help you compile C99 for the Piccolo DSP?
>
I guess , mainstream platforms are for C99.
Greets
Nick
> Michael Tsang wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Kenny McCormack wrote:
>>
>>> In article <ko2e57-...@news.eternal-september.org>,
>>> Richard <rgr...@gmail.com> wrote:
>>>> Mark Bluemel <mark.b...@googlemail.com> writes:
>>>>
>>>>> On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
>>>>>> Hi,
>>>>>> A)Is it possible to declare a variable inside for loop like
>>>>>> for(int i=100;i>=0;i--);
>>>>> Not in C.
>>>> Huh? What C do you use?
>>>>
>>>> Not only can you, its recommended.
>>> In the religion of comp.lang.c, nothing exists past C89.
>>>
>>> Therefore, it (the declarations which are the subject of this thread)
>>> does not exist.
>>
>> C99 is not C?! READ THE STANDARD!
>
> 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".
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Keith Thompson
> Richard Heathfield <r...@see.sig.invalid> writes:
[...]
>> 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.
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.
>
>> 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".
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
> Nick <3-no...@temporary-address.org.uk> writes:
>> Richard Heathfield <r...@see.sig.invalid> writes:
[...]
>> 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.
Richard Heathfield
<snip>
> You do sometimes take a position that because there are no C99
> compilers, code using any of these isn't "proper" C.
Um, I hope I *don't* take that position. De jure is important too (and
in any case there /are/ some C99 compilers - not many, but some).
> 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.
I agree.
> 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.
Right.
>> 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.
This is turning into an AOL reply. Yes, again I agree.
> 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".
On several occasions in the past (and, I think, just a day or so ago) I
have posted a list of conforming C99 compilers, so please believe me
when I say I'm well aware of their existence. I would therefore hope you
can accept that I am not terribly likely to claim otherwise.