labels on declarations
Thomas Pornin
C99 specifies this grammar:
statement:
labeled-statement
| compound-statement
| expression-statement
| selection-statement
| iteration-statement
| jump-statement
compound-statement:
"{" block-item-list opt "}"
block-item-list:
block-item
| block-item-list block-item
block-item:
declaration
| statement
which means that a declaration cannot have a label. Therefore, this
code is not correct:
int
main(void)
{
goto foo;
foo:
int x = 0;
return x;
}
gcc-3.3 rightly rejects that code with a syntax error.
This code is correct:
int
main(void)
{
goto foo;
foo:;
int x = 0;
return x;
}
because it puts the label on a statement, not a declaration.
I then have two questions:
1. This seems to be an arbitrary limitation. Why is it there ? Is there
a profund reason why labels must not be permitted on declarations, or
is it just an oversight ?
2. How comes the Rationale (n897.pdf) contains such invalid code
(page 86) ?
--Thomas Pornin
Douglas A. Gwyn
> 1. This seems to be an arbitrary limitation. Why is it there ? Is there
> a profund reason why labels must not be permitted on declarations, or
> is it just an oversight ?
Labels have never been permitted on declarations, which
are not statements. This harks back to Fortran, if not
earlier.
The distinction between statements, which are executed,
and declarations, which are not executed, is not as
strong as it once was, but there seems to be no real
need to try to change it now.
> 2. How comes the Rationale (n897.pdf) contains such invalid code
> (page 86) ?
It's an error, presumably due to insufficient review.
Tony Finch
>
>The distinction between statements, which are executed,
>and declarations, which are not executed, is not as
>strong as it once was, but there seems to be no real
>need to try to change it now.
Declarations with initializers and VLA declarations are executed.
Tony.
--
f.a.n.finch <d...@dotat.at> http://dotat.at/
SOUTH UTSIRE: EAST OR SOUTHEAST 3 OR 4, OCCASIONALLY 5 IN SOUTH AT FIRST.
FAIR. GOOD.
Paul Eggert
> Is there a profund reason why labels must not be permitted on
> declarations, or is it just an oversight ?
No good reason, really, now that statements and declarations can
mostly be intermixed. But it's longstanding tradition. Labels are
considered bad in many quarters, so there would probably be some
opposition to liberalizing their use.
> 2. How comes the Rationale (n897.pdf) contains such invalid code
> (page 86) ?
People don't always remember unnecessary restrictions like that, and
they sometimes make mistakes.
jacob navia
"Thomas Pornin" <por...@nerim.net> a écrit dans le message de
news:cedmfs$1l8r$1...@biggoron.nerim.net...
> Hello,
>
> 2. How comes the Rationale (n897.pdf) contains such invalid code
> (page 86) ?
That is NOT a bug... It is a feature!!! :-)
If we make labels valid at the start of a declaration we could
then do:
outerloop:
for (int i=0; i<10;i++) {
for (int j=0; j<10;j++) {
// ...
continue outerloop;
// ...
break outerloop;
}
}
The anonymous writer of the rationale was just foreseeing
that the standard will allow this. It is a hint!
We have discussed this here several times, and everybody agreed that
this hole in the language could be filled very elegantly with
a solution like this.
jacob
Keith Thompson
I don't see the connection. I agree that named continue and break
statements would be a good feature, but the "outerloop:" label is on a
statement, not on a declaration.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Francis Glassborow
<DAG...@null.net> writes
>Thomas Pornin wrote:
>> 1. This seems to be an arbitrary limitation. Why is it there ? Is there
>> a profund reason why labels must not be permitted on declarations, or
>> is it just an oversight ?
>
>Labels have never been permitted on declarations, which
>are not statements. This harks back to Fortran, if not
>earlier.
>
>The distinction between statements, which are executed,
>and declarations, which are not executed, is not as
>strong as it once was, but there seems to be no real
>need to try to change it now.
In the days when declarations had to be at the start of a block before
anything else the restriction made sense however now we allow late
declarations it seems rather hollow and I think we need to address the
issue of 'redefinition' caused by code such as:
int main(){
loop: 1;
int i = 0;
scanf("%d", &i);
printf("%d" i*i);
if(i != 0) goto loop;
}
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
jacob navia
"Keith Thompson" <ks...@mib.org> a écrit dans le message de
news:lnpt6cl...@nuthaus.mib.org...
> "jacob navia" <ja...@jacob.remcomp.fr> writes:
> > "Thomas Pornin" <por...@nerim.net> a écrit dans le message de
> > news:cedmfs$1l8r$1...@biggoron.nerim.net...
>
> statements would be a good feature, but the "outerloop:" label is on a
> statement, not on a declaration.
Yes. It was a shameless plug anyway :-)
Douglas A. Gwyn
> issue of 'redefinition' caused by code such as:
> int i = 0;
> scanf("%d", &i);
> printf("%d" i*i);
> if(i != 0) goto loop;
I thought we had already addressed the "jump and
initializers" issue?
Francis Glassborow
<DAG...@null.net> writes
Can you point me to where?
lawrenc...@ugsplm.com
>
> In article <oMSdnbTPqbG...@comcast.com>, Douglas A. Gwyn
> <DAG...@null.net> writes
>>
>>initializers" issue?
>
> Can you point me to where?
6.8p3:
The initializers of objects that have automatic storage
duration, and the variable length array declarators of ordinary
identifiers with block scope, are evaluated and the values are
stored in the objects (including storing an indeterminate value
in objects without an initializer) each time the declaration is
reached in the order of execution, as if it were a statement,
and within each declaration in the order that declarators
appear.
-Larry Jones
I can do that! It's a free country! I've got my rights! -- Calvin
Francis Glassborow
writes
>Francis Glassborow <fra...@robinton.demon.co.uk> wrote:
>>
>> In article <oMSdnbTPqbG...@comcast.com>, Douglas A. Gwyn
>> <DAG...@null.net> writes
>>>
>>>I thought we had already addressed the "jump and
>>>initializers" issue?
>>
>> Can you point me to where?
>
>6.8p3:
>
> The initializers of objects that have automatic storage
> duration, and the variable length array declarators of ordinary
> identifiers with block scope, are evaluated and the values are
> stored in the objects (including storing an indeterminate value
> in objects without an initializer) each time the declaration is
> reached in the order of execution, as if it were a statement,
> and within each declaration in the order that declarators
> appear.
Thanks, I had forgotten that; it works for C because objects do not have
destructors but does not work for C++.
David Hopwood
> 6.8p3:
>
> The initializers of objects that have automatic storage
> duration, and the variable length array declarators of ordinary
> identifiers with block scope, are evaluated and the values are
> stored in the objects (including storing an indeterminate value
> in objects without an initializer) each time the declaration is
> reached in the order of execution, as if it were a statement,
> and within each declaration in the order that declarators
> appear.
This is a little sloppily worded; I would have thought that each time
the declaration is reached would create a new object, not just store
a value in the same object. Here is an example to test that: does
int *p;
int i;
for (i = 0; i < 10; i++) {
int x = i;
if (i > 0) printf("%d", *p);
p = &x;
}
have undefined behaviour? (I think it does, since there are 10 different
x objects, and the previous &x has gone out of scope on each iteration.)
David Hopwood <david.nosp...@blueyonder.co.uk>
Douglas A. Gwyn
>> 6.8p3: ...
> This is a little sloppily worded; I would have thought that each time
> the declaration is reached would create a new object, not just store
> a value in the same object.
It doesn't say that it's the same object each time.
It is definitely *not* guaranteed to be a new object
(with its own distinct address).
lawrenc...@ugsplm.com
>
> This is a little sloppily worded; I would have thought that each time
> the declaration is reached would create a new object, not just store
> a value in the same object.
No. Objects are created when the containing block is entered, not when
the declaration is reached. If the declaration is reached multiple
times without leaving and reentering the block (via a goto, for
example), you're guaranteed that it's the same object. Between the time
the block is entered and the time the declaration is reached, the object
has an unspecified value.
-Larry Jones
Who, ME? Who?! Me?? WHO... Me?! Who, me??? -- Calvin
David Hopwood
A new object would not necessarily have a distinct address, since the
previous object has gone out of scope. So it might as well be modelled
as a new object.
David Hopwood <david.nosp...@blueyonder.co.uk>
David Hopwood
Thankyou, that clarifies the intent, although I'm not sure that it is what
the standard literally says. Under that interpretation, however, the
program I gave:
int *p;
int i;
for (i = 0; i < 10; i++) {
int x = i;
if (i > 0) printf("%d", *p);
p = &x;
}
has defined behaviour: it must print "123456789" (and indeed, that is what
gcc prints, perhaps by coincidence). Is this intentional?
David Hopwood <david.nosp...@blueyonder.co.uk>
jacob navia
"David Hopwood" <david.nosp...@blueyonder.co.uk> a écrit dans le
message de news:TgbQc.81418$28.2...@fe1.news.blueyonder.co.uk...
> lawrenc...@ugsplm.com wrote:
>
> Thankyou, that clarifies the intent, although I'm not sure that it is what
> the standard literally says. Under that interpretation, however, the
> program I gave:
>
> int *p;
> int i;
> for (i = 0; i < 10; i++) {
> int x = i;
> if (i > 0) printf("%d", *p);
> p = &x;
> }
>
> has defined behaviour: it must print "123456789" (and indeed, that is what
> gcc prints, perhaps by coincidence). Is this intentional?
lcc-win32 prints that too. What else would you
expect?
Anyway, this would be more challenging:
for (i = 0; i < 10; i++) {
int x[i+1];
x[0] = i;
David Hopwood
> "David Hopwood" <david.nosp...@blueyonder.co.uk> a écrit dans le
> message de news:TgbQc.81418$28.2...@fe1.news.blueyonder.co.uk...
>
>>lawrenc...@ugsplm.com wrote:
>>
>>Thankyou, that clarifies the intent, although I'm not sure that it is what
>>the standard literally says. Under that interpretation, however, the
>>program I gave:
>>
>> int *p;
>> int i;
>> for (i = 0; i < 10; i++) {
>> int x = i;
>> if (i > 0) printf("%d", *p);
>> p = &x;
>> }
>>
>>has defined behaviour: it must print "123456789" (and indeed, that is what
>>gcc prints, perhaps by coincidence). Is this intentional?
>
> lcc-win32 prints that too. What else would you expect?
I would expect "123456789", but only because I know how gcc allocates
non-VLA auto variables.
> Anyway, this would be more challenging:
>
> for (i = 0; i < 10; i++) {
> int x[i+1];
> x[0] = i;
> if (i > 0) printf("%d", *p);
> p = &x[0];
> }
gcc -std=c99 -pedantic on x86 says "123156799". I'm not going to attempt to
explain why -- but doesn't it show that x cannot be considered the same
object on each iteration -- either in this case or in the previous case?
David Hopwood <david.nosp...@blueyonder.co.uk>
lawrenc...@ugsplm.com
>
> int *p;
> int i;
> for (i = 0; i < 10; i++) {
> int x = i;
> if (i > 0) printf("%d", *p);
> p = &x;
> }
>
> has defined behaviour:
NO! The body of the for loop is a block that is entered *and exited* on
each iteration of the loop, so p is pointing to an object that no longer
exists.
-Larry Jones
Life's a lot more fun when you're not responsible for your actions. -- Calvin
David R Tribble
> Objects are created when the containing block is entered, not when
> the declaration is reached. If the declaration is reached multiple
> times without leaving and reentering the block (via a goto, for
> example), you're guaranteed that it's the same object. Between the time
> the block is entered and the time the declaration is reached, the object
> has an unspecified value.
That being the case, I see no reason not to correct the syntax to allow
labels on declarations within blocks, especially in light of the fact that
initializers in such declarations are executed as assignment statements.
E.g.:
{
loop:
int count;
int ch = EOF;
...
}
I propose the following changes to §6.8:
statement:
declaration <<
labeled-statement
compound-statement
expression-statement
selection-statement
iteration-statement
jump-statement
compound-statement:
{ statement-list/opt } <<
statement-list: <<
statement <<
statement-list statement <<
-drt
Eric Sosman
> Lawrence Jones wrote:
>
>>Objects are created when the containing block is entered, not when
>>the declaration is reached. If the declaration is reached multiple
>>times without leaving and reentering the block (via a goto, for
>>example), you're guaranteed that it's the same object. Between the time
>>the block is entered and the time the declaration is reached, the object
>>has an unspecified value.
>
>
> That being the case, I see no reason not to correct the syntax to allow
> labels on declarations within blocks, especially in light of the fact that
> initializers in such declarations are executed as assignment statements.
> E.g.:
>
> {
> loop:
> int count;
> int ch = EOF;
> ...
> }
You can get the desired effect with a one-character
change to the code and no change at all to the Standard:
{
loop:;
int count;
int ch = EOF;
...
}
David R Tribble
>> I see no reason not to correct the syntax to allow
>> labels on declarations within blocks, especially in light of the fact that
>> initializers in such declarations are executed as assignment statements.
>> E.g.:
>>
>> {
>> loop:
>> int count;
>> int ch = EOF;
>> ...
>> }
Eric Sosman wrote:
> You can get the desired effect with a one-character
> change to the code and no change at all to the Standard:
>
> {
> loop:;
> int count;
> int ch = EOF;
> ...
> }
Sure, but that's just ugly.
Here's a two-character "fix" that's just as ugly:
label:{}
int c;
-drt
Niklas Matthies
In many situations the real fix is:
loop: {
int count;
int ch = EOF;
...
}
-- Niklas Matthies
Eric Sosman
> David R Tribble wrote:
>
>>>I see no reason not to correct the syntax to allow
>>>labels on declarations within blocks, especially in light of the fact that
>>>initializers in such declarations are executed as assignment statements.
>>>E.g.:
>>>
>>> {
>>> loop:
>>> int count;
>>> int ch = EOF;
>>> ...
>>> }
>
>
> Eric Sosman wrote:
>
>>You can get the desired effect with a one-character
>>change to the code and no change at all to the Standard:
>>
>> {
>> loop:;
>> int count;
>> int ch = EOF;
>> ...
>> }
>
>
> Sure, but that's just ugly.
It's far from the ugliest feature of the language,
in the eye of this beholder at any rate. (I'm as yet
undecided on whether the ugliest bit is `SCNuFAST16' or
`long long'.)
However, I cannot but admire the dedication of
someone who's willing to go through all the pain and
frustration of amending an International Standard
simply to uphold his sense of aesthetics.
Keith Thompson
> David R Tribble wrote:
> >> I see no reason not to correct the syntax to allow labels on
> >> declarations within blocks, especially in light of the fact that
> >> initializers in such declarations are executed as assignment
> >> statements.
> >> E.g.:
> >>
> >> {
> >> loop:
> >> int count;
> >> int ch = EOF;
> >> ...
> >> }
>
> Eric Sosman wrote:
> > You can get the desired effect with a one-character
> > change to the code and no change at all to the Standard:
> >
> > {
> > loop:;
> > int count;
> > int ch = EOF;
> > ...
> > }
>
> Sure, but that's just ugly.
Yes, and it probably should be ugly. Labels are used for gotos and
for switch statements. Gotos aren't inherently evil, but they are,
after all, "considered harmful". If a declaration immediately follows
a label in a switch statement, that branch of the switch should
probably be enclosed in braces anyway.
I don't believe we should change the language standard just to help
make conceptually ugly code slightly less visually ugly. And even if
such a change were made to the standard, it wouldn't do much good for
programmers until the successor to the C99 standard supplants the C90
and C99 standards.
Can someone provide an example where a label on a declaration is
really the best way to write something?
David Hopwood
> However, I cannot but admire the dedication of
> someone who's willing to go through all the pain and
> frustration of amending an International Standard
> simply to uphold his sense of aesthetics.
Let that be a warning to promoters of International
Standardisation for other languages. :-)
David Hopwood <david.nosp...@blueyonder.co.uk>
Chris Hills
Hopwood <david.nosp...@blueyonder.co.uk> writes
One view I have seen expressed by a couple of ISO C standards people
(who know what they are talking about) is that the ISO C definition of
the language will give way to the GNU C definition by default. IE there
are more people using the GNU definition than the ISO and commercial
compiler vendors will, by 2015, move over to it.
That is NOT to say people will be using GNU compilers.
I queried this when I first heard it but the arguments are compelling.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Tony Finch
>
>One view I have seen expressed by a couple of ISO C standards people
>(who know what they are talking about) is that the ISO C definition of
>the language will give way to the GNU C definition by default. IE there
>are more people using the GNU definition than the ISO and commercial
>compiler vendors will, by 2015, move over to it.
In that case the gratuitous incompatibilities between C99 and GNU C
are even more inexplicable.
Tony.
--
f.a.n.finch <d...@dotat.at> http://dotat.at/
HEBRIDES BAILEY: SOUTHEAST 4 OR 5 BACKING EAST 6 OR 7. RAIN OR SHOWERS.
MODERATE OR GOOD.
Douglas A. Gwyn
> Chris Hills <ch...@phaedsys.org> wrote:
>>One view I have seen expressed by a couple of ISO C standards people
>>(who know what they are talking about) is that the ISO C definition of
>>the language will give way to the GNU C definition by default. IE there
>>are more people using the GNU definition than the ISO and commercial
>>compiler vendors will, by 2015, move over to it.
I doubt that that is an accurate portrayal of whatever
might have been meant by anyone who does know what he
is talking about.
> In that case the gratuitous incompatibilities between C99 and GNU C
> are even more inexplicable.
Perhaps you should talk to the GNU C developers about that.
Chris Hills
<DAG...@null.net> writes
>Tony Finch wrote:
>> Chris Hills <ch...@phaedsys.org> wrote:
>>>One view I have seen expressed by a couple of ISO C standards people
>>>(who know what they are talking about) is that the ISO C definition of
>>>the language will give way to the GNU C definition by default. IE there
>>>are more people using the GNU definition than the ISO and commercial
>>>compiler vendors will, by 2015, move over to it.
>
>I doubt that that is an accurate portrayal of whatever
>might have been meant by anyone who does know what he
>is talking about.
Well I was surprised too but the two people concerned were very
persuasive in their argument. Both have been doing C Standards for over
a decade. I then asked another long standing member of the C Panel who
has a lot of real experience in the industry and he concluded that the
other two were right.
The rational was that a vast number of people use GNU C on virtually
every target processor there is including some where there are no ISO C
compilers. Linux has helped spread the GNU-C take up. There is a vast
amount of GNU-C compatible code about including libraries.
Therefore many commercial compiler vendors who are getting into the
Linux market and also the ARM market (where GNU is widely used) was
looking to have computability with GNU rather than 9899:99. Especially
as most of the embedded market is C90 or C95 compliant not C99. IE they
a moving from C90/95 to Gnu rather than C99 or C05.
I have discussed this with a couple of C compiler writers I know and
whilst there is not a conscious move to drop C99 they were looking to
have GNU-C compatibility.
This only came up in the last month and as I said it surprised me but
does appear to be happening. This could make the whole ISO C process
irrelevant.
What I can't understand is why is GNU different to ISO C in the first
place? I would have thought that it would have been in the interest of
the GNU crowd to have been compatible. I think part of the problem (from
their point of view) is that the ISO C standard is not freely available
(and free).
That said I have found the GNU compilers very inefficient and apart from
being "free" I can't see the advantage. This is why I was initially
sceptical of the claim that Gnu would rule. However it is not the
compilers but the GNU "standard" that would be used on commercial
compilers
Regards
Chris
PS I am off-line for the next three days and not ignoring any reply.
Thomas Pornin
> Can someone provide an example where a label on a declaration is
> really the best way to write something?
As the original poster, I can at least tell why I raised the subject.
I was acting as a proxy for someone else, whose is writing a compiler
for some other language. The compiler produces C code, with labels and
goto's and many local declarations. Interleaving the declarations with
the statements (instead of regrouping all declarations at the beginning
of the block) saves one compiler pass; but it also exhibits the problem
(some labels apply to declarations).
Adding a ";" after each label completely fixes the problem (and ugliness
is not revelant, since the C code is automatically generated and not
meant for human readability). However, the fact that labels are not
allowed on declarations is, at first, surprising, and is not really
justified except for historical reasons. I was hoping to find in
the Rationale some explanation (probably along the lines of "when
interleaved declarations and statements was implemented, it was easier
for some vendors not to support labels on declarations"). But I found
none of this; instead, I found an incorrect example. Hence my posting
here.
Therefore, I think that either the Standard or the Rationale should be
corrected, since they currently disagree. Amending the Rationale is
probably much easier, although I find, on a purely conceptual plane, the
current standard limitation arbitrary and lacking of symmetry.
--Thomas Pornin
lawrenc...@ugsplm.com
>
> In that case the gratuitous incompatibilities between C99 and GNU C
> are even more inexplicable.
Gratuitous incompatibilties? There are incompatibilities, but I don't
think any of them are gratuitous.
-Larry Jones
Nothing spoils fun like finding out it builds character. -- Calvin
Dave Thompson
> David Hopwood <david.nosp...@blueyonder.co.uk> wrote:
> >
> > This is a little sloppily worded; I would have thought that each time
> > the declaration is reached would create a new object, not just store
> > a value in the same object.
>
> No. Objects are created when the containing block is entered, not when
> the declaration is reached. If the declaration is reached multiple
> times without leaving and reentering the block (via a goto, for
> example), you're guaranteed that it's the same object. Between the time
Except for VLAs. Which might have a different size on "reexecution" of
the declaration, and so need to be (placed) at a different location.
> the block is entered and the time the declaration is reached, the object
> has an unspecified value.
>
Nit: indeterminate. That means it is UB to even fetch it; it could be
a trap representation, although I believe no one has identified any
actual platforms on which integer types have trap rep.s. An
unspecified value would have to be a value, and thus valid, even
though formally unknown, possibly unknowable and probably useless.
- David.Thompson1 at worldnet.att.net
Douglas A. Gwyn
> ... I believe no one has identified any
> actual platforms on which integer types have trap rep.s.
Actually several such platforms are known.
Perhaps you'tre misled by the name "trap representation";
such representations need not cause an actual trap when
accessed of used, they merely need not meet the format
requirements for representation of the given type.
Douglas A. Gwyn
Tony Finch
>
>What I can't understand is why is GNU different to ISO C in the first
>place? I would have thought that it would have been in the interest of
>the GNU crowd to have been compatible. I think part of the problem (from
>their point of view) is that the ISO C standard is not freely available
>(and free).
When the GNU C extensions where created they didn't have anything to be
compatible with. C99 later extended the language in ways which are not
quite the same as GNU C, though there is a fair amount of overlap.
Tony.
--
f.a.n.finch <d...@dotat.at> http://dotat.at/
BERWICK ON TWEED TO WHITBY: EAST OR SOUTHEAST 4 OR 5 OCCASIONALLY 6. RAIN AT
TIMES. MODERATE WITH FOG PATCHES. MODERATE OR ROUGH.
Francis Glassborow
<d...@dotat.at> writes
>Chris Hills <ch...@phaedsys.org> wrote:
>>
>>What I can't understand is why is GNU different to ISO C in the first
>>place? I would have thought that it would have been in the interest of
>>the GNU crowd to have been compatible. I think part of the problem (from
>>their point of view) is that the ISO C standard is not freely available
>>(and free).
>
>When the GNU C extensions where created they didn't have anything to be
>compatible with. C99 later extended the language in ways which are not
>quite the same as GNU C, though there is a fair amount of overlap.
And IIRC WG14 repeatedly asked the developers of GNU C for input about
potential incompatibilities whilst C99 was under development.
I remain slightly amused by the thesis that GNU C will become a de facto
Standard whilst the same people decry MS's non-proprietary extensions to
C. Why is one OK and the other not?
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Brian Inglis
<fra...@robinton.demon.co.uk> wrote:
>In article <luq*7w...@news.chiark.greenend.org.uk>, Tony Finch
><d...@dotat.at> writes
>>Chris Hills <ch...@phaedsys.org> wrote:
>>>
>>>What I can't understand is why is GNU different to ISO C in the first
>>>place? I would have thought that it would have been in the interest of
>>>the GNU crowd to have been compatible. I think part of the problem (from
>>>their point of view) is that the ISO C standard is not freely available
>>>(and free).
>>
>>When the GNU C extensions where created they didn't have anything to be
>>compatible with. C99 later extended the language in ways which are not
>>quite the same as GNU C, though there is a fair amount of overlap.
>
>And IIRC WG14 repeatedly asked the developers of GNU C for input about
>potential incompatibilities whilst C99 was under development.
>
>I remain slightly amused by the thesis that GNU C will become a de facto
>Standard whilst the same people decry MS's non-proprietary extensions to
>C. Why is one OK and the other not?
What do you mean by MS *NON-proprietary* extensions to C?
Their compiler and library are proprietary products for a single
platform, and their license makes it illegal to reverse-engineer or
change them.
Does the MS compiler support compiling conforming code, and reject
non-conforming code?
I know that some of the GNU C extensions are to allow compilers to be
built for the many supported platforms, and to avoid namespace
pollution as far as possible on those platforms.
GNU C is a free product for many platforms, and their licence gives
you the right to change it in any way you wish.
GCC supports compiling conforming code written to various standards
levels, and rejects non-conforming code.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
jacob navia
"Brian Inglis" <Brian....@SystematicSw.Invalid> a écrit dans le message
de news:6befh05s1mqibb29d...@4ax.com...
> On Mon, 9 Aug 2004 12:48:31 +0100 in comp.std.c, Francis Glassborow
> Their compiler and library are proprietary products for a single
> platform, and their license makes it illegal to reverse-engineer or
> change them.
I made lcc-win32 accept __declspec(dllexport), for instance,
and nobody cares. You do not have to disassemble the compiler
to use an extension...
I do not even know if you can copyright
__declspec()...
Of course it would be better if the standard would not be
gcc or msvc but a standard language definition. This discussion
makes me believe that nobody really wants to develop the C language as
such, not even the standards commitee. Let's get rid of C and concentrate
on C++, the better C.
This is really discouraging
jacob
Francis Glassborow
<ja...@jacob.remcomp.fr> writes
>I made lcc-win32 accept __declspec(dllexport), for instance,
>and nobody cares. You do not have to disassemble the compiler
>to use an extension...
Thank you for the example. There are many aspects of Visual C which are
widely emulated by other implementations and I am not aware that MS
cares or even wants to claim any rights over such things.
>
>I do not even know if you can copyright
>__declspec()...
Probably not, but I suppose it might have been possible to patent it.
>
>Of course it would be better if the standard would not be
>gcc or msvc but a standard language definition. This discussion
>makes me believe that nobody really wants to develop the C language as
>such, not even the standards commitee. Let's get rid of C and concentrate
>on C++, the better C.
MS cares enough about Standard C to ask WG14 to extend the Standard C
Library with a number of functions aimed at increasing security by
reducing such things as buffer overruns.
Unlike Chris Hills, I meet regularly with the whole of WG14 (twice a
year for five days at a time) as well as meeting individual members at
other times. I do not think that either the individuals or the companies
the represent would support the view attributed to them or at least to a
couple of unnamed members.
Indeed, I am very unhappy that such comments should be made by someone
who is supposedly representing the BSI (or at least is convenor of its
Panel for the C Standard). If it were believed it could be damaging to
the relationship between the GNU community and WG14 (and possibly also
with WG21) at a time when all concerned have been working very hard to
build bridges and work towards common goals.
Claiming unnamed sources can result in sowing distrust. For this reason
it should be avoided, and discounted when it happens. People are well
able to speak for themselves and all the people I know on WG14 are quite
willing to do so if they wish to.
Even among WG21 there are many people who represent companies with a
serious interest in development in C. Those companies, some small, some
large, pay good money to work on Standards.
Harti Brandt
jn>
jn>"Brian Inglis" <Brian....@SystematicSw.Invalid> a Иcrit dans le message
jn>de news:6befh05s1mqibb29d...@4ax.com...
jn>> On Mon, 9 Aug 2004 12:48:31 +0100 in comp.std.c, Francis Glassborow
jn>> What do you mean by MS *NON-proprietary* extensions to C?
jn>> Their compiler and library are proprietary products for a single
jn>> platform, and their license makes it illegal to reverse-engineer or
jn>> change them.
jn>
jn>I made lcc-win32 accept __declspec(dllexport), for instance,
jn>and nobody cares. You do not have to disassemble the compiler
jn>to use an extension...
jn>
jn>I do not even know if you can copyright
jn>__declspec()...
I suppose one could patent it in US.
jn>Of course it would be better if the standard would not be
jn>gcc or msvc but a standard language definition. This discussion
jn>makes me believe that nobody really wants to develop the C language as
jn>such, not even the standards commitee. Let's get rid of C and concentrate
jn>on C++, the better C.
jn>
jn>This is really discouraging
Not really. Standard committes should be conservative to a large extent.
Otherwise the risk to kill the object they are standardizing. My canonical
example of this (from the networking world) is ATM, who's standardisation
body (the ITU-T) was working on at least 10 times the speed of
implementors.
harti
Douglas A. Gwyn
> makes me believe that nobody really wants to develop the C language as
> such, not even the standards commitee.
Nobody on the standards committee wants to invalidate tons
of existing C source code that was carefully written to
obey the existing language specification. That pretty
much limits and linguistic changes to *additions* to the
language. We will consider such additions during the
course of working on an updated standard, *if* a convincing
case is made for them. That generally means that they need
to satisfy some pressing programming requirement that has
no reasonable solution using the existing language. We do
encourage experimentation via actual implementations to
test the worth of proposed new features. One we especially
urged, which so far as I know has not yet been implemented,
is built-in features for requirements-based integer type
specification.
> Let's get rid of C and concentrate on C++, the better C.
C++ isn't (and doesn't try to be) "a better C".
David R Tribble
>> You can get the desired effect with a one-character
>> change to the code and no change at all to the Standard:
>> {
>> loop:;
>> int count;
>> int ch = EOF;
>> ...
>> }
David R Tribble wrote:
>> Sure, but that's just ugly.
Keith Thompson wrote:
> Yes, and it probably should be ugly. Labels are used for gotos and
> for switch statements. Gotos aren't inherently evil, but they are,
> after all, "considered harmful". If a declaration immediately follows
> a label in a switch statement, that branch of the switch should
> probably be enclosed in braces anyway.
>
> I don't believe we should change the language standard just to help
> make conceptually ugly code slightly less visually ugly. And even if
> such a change were made to the standard, it wouldn't do much good for
> programmers until the successor to the C99 standard supplants the C90
> and C99 standards.
>
> Can someone provide an example where a label on a declaration is
> really the best way to write something?
Sure:
read:
read_tok(&tok);
shift:
if (shift_tok(&tok))
goto read;
if (reduce(&tok))
goto shift;
return ACCEPT;
The task of rewriting this without gotos is left as an exercise for
the interested reader.
-drt
Keith Thompson
[...]
> Keith Thompson wrote:
> > Yes, and it probably should be ugly. Labels are used for gotos and
> > for switch statements. Gotos aren't inherently evil, but they are,
> > after all, "considered harmful". If a declaration immediately follows
> > a label in a switch statement, that branch of the switch should
> > probably be enclosed in braces anyway.
> >
> > I don't believe we should change the language standard just to help
> > make conceptually ugly code slightly less visually ugly. And even if
> > such a change were made to the standard, it wouldn't do much good for
> > programmers until the successor to the C99 standard supplants the C90
> > and C99 standards.
> >
> > Can someone provide an example where a label on a declaration is
> > really the best way to write something?
>
> Sure:
>
> read:
> read_tok(&tok);
> shift:
> if (shift_tok(&tok))
> goto read;
> if (reduce(&tok))
> goto shift;
> return ACCEPT;
>
> The task of rewriting this without gotos is left as an exercise for
> the interested reader.
I don't see a label on a declaration in that code fragment; all the
labels apply to statements. In fact, I don't see a declaration at
all.
It can, of course, be rewritten without gotos. Quite possibly the
rewritten version would be less clear (I'm not arguing against all
uses of gotos). But that wasn't the question.
Niklas Matthies
> jacob navia wrote:
:
>> Let's get rid of C and concentrate on C++, the better C.
>
> C++ isn't (and doesn't try to be) "a better C".
Bjarne Stroustrup seems to have a slightly different opinion. His
C++ web page (http://www.research.att.com/~bs/C++.html) starts with:
C++ is a general purpose programming language with a bias towards
systems programming that
· is a better C
[...]
-- Niklas Matthies
Richard Bos
> I remain slightly amused by the thesis that GNU C will become a de facto
> Standard whilst the same people decry MS's non-proprietary extensions to
> C. Why is one OK and the other not?
The suspicion that Ganuck _will_ become a de facto standard does not
necessarily involve the opinion that it _should_.
I agree that one specific embraced-and-extended bastardisation of C will
probably become the de facto standard in a couple of years. My cynicism
tells me it will probably be M$ Sheesh, rather than Ganuck, but it'll
certainly be one of those. This does not mean that I think this is OK -
rather the contrary - but I do think that it will happen.
Richard
David R Tribble
>> Can someone provide an example where a label on a declaration is
>> really the best way to write something?
David R Tribble writes:
>> Sure:
>>
>> read:
>> read_tok(&tok);
>> shift:
>> if (shift_tok(&tok))
>> goto read;
>> if (reduce(&tok))
>> goto shift;
>> return ACCEPT;
Keith Thompson wrote:
> I don't see a label on a declaration in that code fragment; all the
> labels apply to statements. In fact, I don't see a declaration at
> all.
>
> It can, of course, be rewritten without gotos. Quite possibly the
> rewritten version would be less clear (I'm not arguing against all
> uses of gotos). But that wasn't the question.
Oops. In my haste to provide an example, I misread your question.
A better counter-response to your query is to ask:
What's wrong with making the C grammar orthogonal with respect to labels
on declarations and labels on statements? Or perhaps: Is there anything
to be gained by leaving the grammar nonsymmetrical in this regard?
True, this whole thing is a minor issue. But aethestics do play a part
in good language design. And they, arguably, are the entire reason for
this particular newsgroup.
-drt
David R Tribble
>> Let's get rid of C and concentrate on C++, the better C.
jacob navia wrote:
>> C++ isn't (and doesn't try to be) "a better C".
Niklas Matthies wrote:
> Bjarne Stroustrup seems to have a slightly different opinion. His
> C++ web page (http://www.research.att.com/~bs/C++.html) starts with:
>
> C++ is a general purpose programming language with a bias towards
> systems programming that
>
> · is a better C
> [...]
Yes, I don't doubt that he'd like that to be true. Unfortunately, C++
has morphed into a language that bears only superficial resemblance to C.
With the eventual dominance of templates and the STL, we now see rampant
use of iterators for even the simplest of loops, templatization of even
the simplest classes, and an almost religious fervor to eliminate the
preprocessor entirely (remember goto?). Most of the C++ code I see in
magazines and web articles nowadays doesn't even come close to looking
like C. (At least C has that going for it - it's still easy to write
very legible code.)
C++ has its place, but saying it's still close to C, only better, is
a pipe dream. True, it's closer to C than Java, but it requires more
than a simple short step to move from C to C++.
</rant>
-drt
David R Tribble
> If we make labels valid at the start of a declaration we could
> then do:
>
> outerloop:
> for (int i=0; i<10;i++) {
> for (int j=0; j<10;j++) {
> // ...
> continue outerloop;
> // ...
> break outerloop;
> }
> }
>
> We have discussed this here several times, and everybody agreed that
> this hole in the language could be filled very elegantly with
> a solution like this.
To start yet another serious discussion along these lines...
What would it take to add labeled break/continue syntax to ISO C?
The only real difficulty I see is deciding where to place the label:
A label:
for/while/do
statement
or:
B for/while/do
label:
statement
(A) works by placing the label on the looping control (for/while/do)
itself, while (B) works by placing the label on the body of the loop
(which is typically a compound block statement) following the control
portion.
Java, as prior art, employs (A).
There are other minor issues, such as how to handle multiple labels on
a given loop:
bigloop:
reader:
while (!done)
{
...
if (...)
break bigloop; // error?
...
}
-drt
Kevin Bracey
da...@tribble.com (David R Tribble) wrote:
> What's wrong with making the C grammar orthogonal with respect to labels
> on declarations and labels on statements? Or perhaps: Is there anything
> to be gained by leaving the grammar nonsymmetrical in this regard?
The arguments presented so far for leaving it seem to be:
1) An aversion to changing the standard.
2) The harder labels are to use the better, because labels are bad.
I don't agree with either argument. I'm strongly in favour of fixing the
grammar, and regard it as an oversight in C99.
Did C++ fix this wrinkle, btw?
--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1728 727430
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
Douglas A. Gwyn
> I agree that one specific embraced-and-extended bastardisation of C will
> probably become the de facto standard in a couple of years. My cynicism
> tells me it will probably be M$ Sheesh, rather than Ganuck, but it'll
> certainly be one of those. This does not mean that I think this is OK -
> rather the contrary - but I do think that it will happen.
We heard such things being said fifteen years ago,
and it didn't happen then either.
Douglas A. Gwyn
> ... regard it as an oversight in C99.
No, labels on declarations have never been allowed in C.
The real question is, what compelling reason is there
that they *should* be allowed? So far I have not heard
one.
Douglas A. Gwyn
> What would it take to add labeled break/continue syntax to ISO C?
We don't need it:
for/while/do {
stuff
goto label;
stuff
}
label:
Keith Thompson
> In message <f4002eab.04081...@posting.google.com>
> da...@tribble.com (David R Tribble) wrote:
>
> > What's wrong with making the C grammar orthogonal with respect to labels
> > on declarations and labels on statements? Or perhaps: Is there anything
> > to be gained by leaving the grammar nonsymmetrical in this regard?
>
> The arguments presented so far for leaving it seem to be:
>
> 1) An aversion to changing the standard.
> 2) The harder labels are to use the better, because labels are bad.
>
> I don't agree with either argument. I'm strongly in favour of fixing the
> grammar, and regard it as an oversight in C99.
I've raised both arguments myself. What I meant was not necessarily
that they imply the standard *shouldn't* be changed, just that leaving
it alone wouldn't be a terrible thing.
I do agree that orthogonality is a good thing. The only valid
argument I can think of *against* allowing labels on declarations is
backward compatibility (new code with labeled declarations won't
compile on old C99 or C90 compilers), and that's not a very strong
argument. (The same kind of argument could have been made against
allowing mixed declarations and statements in C99.)
At this point, I suppose I'm mildly in favor of fixing the grammar.
> Did C++ fix this wrinkle, btw?
Yes. The C++ grammar only allows a label on a statement, but a
declaration is considered to be a kind of statement.
Keith Thompson
> What would it take to add labeled break/continue syntax to ISO C?
>
> The only real difficulty I see is deciding where to place the label:
>
> A label:
> for/while/do
> statement
>
> or:
>
> B for/while/do
> label:
> statement
>
>
> (A) works by placing the label on the looping control (for/while/do)
> itself, while (B) works by placing the label on the body of the loop
> (which is typically a compound block statement) following the control
> portion.
>
> Java, as prior art, employs (A).
All the prior art I'm aware of uses (A) (Ada, Perl). I don't know of
any language that uses (B), and I find it counterintuitive.
Niklas Matthies
> Niklas Matthies wrote:
> > Douglas A. Gwyn wrote:
> > >
> > > > Let's get rid of C and concentrate on C++, the better C.
> > >
> >
> > C++ web page (http://www.research.att.com/~bs/C++.html) starts with:
> >
> > C++ is a general purpose programming language with a bias towards
> > systems programming that
> >
> > · is a better C
> > [...]
>
> Yes, I don't doubt that he'd like that to be true. Unfortunately, C++
> has morphed into a language that bears only superficial resemblance to C.
The point is that you _can_ use it as a better C.
You don't have to use non-POD classes, operator overloading,
exceptions, templates, the STL, template meta programming etc.
C++ always had the philosphy that it doesn't impose a particular
paradigm, but rather lets the programmer choose which features to use.
-- Niklas Matthies
Christian Bau
Because there is not that much difference between a declaration with
initialisation and an assignment statement, especially in C99, where
declarations can occur at any point. Not allowing labels before
declarations seems an artifical restriction.
I would have actually preferred if there was a "label-statement",
consisting of an identifier followed by a colon, which could appear
anywhere a normal statement can appear.
Eric Sosman
>
> I would have actually preferred if there was a "label-statement",
> consisting of an identifier followed by a colon, which could appear
> anywhere a normal statement can appear.
A few details would need to be worked out, I think.
for (int i = 0; i < 10; ++i)
label_statement: /* the loop body */
puts ("Hello");
One line of output, or ten? The latter, presumably, on
the assumption that the C0x committee might be reluctant
to change the meaning the above snippet has had since C
was first invented -- which means that the grammar must not
recognize a "label-statement" when a "labelled-statement"
could apply. The only two contexts I can think of where
this might occur would be before declarations and before
`}'. Neither seems tremendously useful, to me at least.
Keith Thompson
Prior to C99, allowing labels on declarations wouldn't have made much
sense. Since C99 allows statements and declarations to be intermixed,
allowing labels on statements but not on declarations seems at least
mildly non-orthogonal.
I'm not saying that's a *compelling* reason.
(Also, C++ allows labels on declarations; that's not compelling
either, but all else being equal there's little reason for C and C++
to be inconsistent.)
Keith Thompson
We don't need while loops either:
top_of_while_loop: if (!condition) goto bottom_of_while_loop;
statement;
goto top_of_while_loop;
bottom_of_while_loop:;
(I think I got that right.)
Douglas A. Gwyn
> The point is that you _can_ use it as a better C.
To the extent that one uses only the features of C++
that have direct C counterparts, C++ isn't appreciably
better than C. It *is* different in some ways, but
the differences don't buy anything useful.
Douglas A. Gwyn
> We don't need while loops either: ...
True, but there is a significant difference in the
degree of code bloat in substituting the more basic
code for the fancier construct in the two cases.
In the case of labeled breaks, one needs the label
itself, some form of break directive along with the
name of the desired label, and punctuation. The
equivalent code I exhibited is about as small as
one could get away with, and is essentially the
same as was proposed (especially the version with
label at end of loop), except mine used a shorter
keyword. Therefore I have to ask again, what
purpose would be served by the proposed alternative?
It adds bulk but not substance.
Keith Thompson
If you need to break out from the middle of a non-nested loop, do you
use a break statement or a goto? Why?
The existing break and continue statements could be replaced with
equally terse goto equivalents, but they were thought to be important
enough to put into the language in the first place. (Actually, they
were probably inherited from B or BCPL, or even something older.)
If I see a goto statement, I start to worry. Part of that is
goto-phobia induced by my early training, but part of it is that it
makes the code harder to follow. The real problem isn't the goto,
it's the label. Once I see a label, I have to worry about whether
there's another goto targeting that label from anywhere else in the
function. This can be alleviated by using all-caps for label names so
they stand out, and by choosing good mnemonic label names; this lets
you write code that's a bit closer to what it would have been if the
language had labeled break/continue in the first place.
(My argument is slightly weakened by the fact that most proposals for
labeled break/continue use the existing label syntax, so there could
*still* be a rogue goto somewhere else in the function. I'd advocate
a distinct syntax if I could think of a good one.)
See also Edsger W. Dijkstra's classic remarks at
<http://www.acm.org/classics/oct95/>.
No, we don't *need* labeled break/continue; the world isn't going to
end if it's not added to C0X. But in my opinion, this feature
*should* be in the language, for the same reason that non-labeled
break/continue should be in the language.
Niklas Matthies
This lies in the eyes of the beholder, I suppose. :)
-- Niklas Matthies
Jonathan Coxhead
> The arguments presented so far for leaving it seem to be:
>
> 1) An aversion to changing the standard.
> 2) The harder labels are to use the better, because labels are bad.
>
> I don't agree with either argument. I'm strongly in favour of fixing the
> grammar, and regard it as an oversight in C99.
What about
3) It doesn't make sense to have a label after a declaration.
?
ALGOL 68 got this right---a block ("unit", I think) was a sequence of
statements-or-declarations (no labels allowed), followed by a sequence of
possibly-labelled-statements. This is to avoid cases like
{
if (f()) goto L0;
int n = 3;
L0:
printf ("%d\n", n); // 3 or junk? Is n even declared at this point?
}
so it means that we don't have to worry about what happens if you jump "over" a
declaration. A consequence is that you can never have a labelled declaration.
(I hope I remembered that right from 20 years ago!)
Douglas A. Gwyn
> If you need to break out from the middle of a non-nested loop, do you
> use a break statement or a goto? Why?
It depends; it could be either. The important thing is
that *all* paths out of the loop are verified to maintain
the loop invariant, or else constitute a true exception
(in which case the whole purpose of the loop has failed
anyway).
> The existing break and continue statements could be replaced with
> equally terse goto equivalents, but they were thought to be important
> enough to put into the language in the first place. ...
They save inventing an artificial label. The same
cannot be said for the proposed labeled-break feature.
> If I see a goto statement, I start to worry.
We're not discussing unrestrained use of goto, but
rather the proposed labeled-break and equivalent
that just happens to use goto. The point is, the
difference is entirely a minor matter of syntax.
Goto is already part of the language, so there is
already a "just as good" way to code a labeled-
break without adding redundant syntax.
> See also Edsger W. Dijkstra's classic remarks at
> <http://www.acm.org/classics/oct95/>.
Yes, that is about problems in the unrestricted use
of goto, not the subject under discussion.
Thomas Pornin
> Kevin Bracey wrote:
> > ... regard it as an oversight in C99.
>
> No, labels on declarations have never been allowed in C.
Prior to C99, interleaving declarations and statements was not
allowed either -- and yet it is now allowed. So what ?
My real question is not a plea for allowing it or something like that.
The real question is: why is it like that ? In C90, interleaving
declarations and statements was not allowed. There were declarations,
and there were statements, and a "goto" to a declaration made little
sense. Then, at some point, a proposal was made and the growing C9X
draft was amended, to the effect that declarations interleaved with
statements became valid. This amendment was not dictated by the gods
and subsequently delivered to the committee and hammered down into the
draft by Thor himself, threatening to smite contradictors with lightning
bolts(*). The whole process was supposedly a fully human endeavour.
Therefore, when the grammar was changed, the committee was absolutely
free to do it one way or the other. Making declarations some sort of
statement (and, as such, eligible for labels) was possible with no more
definition nor implementation hassle than the actual C99 behaviour.
So it *could* be allowed, as far as I know. At least, I have not
read nor heard any reason why it could not or would have proved
more difficult to define or implement. Yet it was not allowed,
quite arbitrarily. What compelling reason _was_ there that labeled
declarations *should not* be allowed ? In the absence of compelling
reasons one way or the other, non-compelling reasons (e.g., aesthetics)
should have prevailed.
I quite understand that changing the standard _now_ is a complex task.
This _is_ a compelling reason why allowing labels on declarations
should not be allowed _now_, because allowing them would imply changing
the standard. But I use a past tense. When the decision was made, it
was easy to allow labels on declarations. I would like to know the
historical reasons which prevented such labels from becoming allowed. I
would be perfectly happy with a simple statement such as: "at that time,
one vendor implemented interleaved declarations and statements but not
labels on statements, and was reluctant to change a single line of its
own code". Or even: "nobody thought about it or bothered to raise the
issue".
If I have one plea, then it is the following: amend the damn Rationale,
it contains an incorrect example.
--Thomas Pornin
(*) Or was it ? It would explain quite a lot.
Tony Finch
>da...@tribble.com (David R Tribble) writes:
>>
>> The only real difficulty I see is deciding where to place the label:
>>
>> A label:
>> for/while/do
>> statement
>>
>> label:
>> statement
>>
>> (A) works by placing the label on the looping control (for/while/do)
>> itself, while (B) works by placing the label on the body of the loop
>> (which is typically a compound block statement) following the control
>> portion.
>
>any language that uses (B), and I find it counterintuitive.
B also doesn't make sense w.r.t. re-evaluation of the loop condition.
Tony.
--
f.a.n.finch <d...@dotat.at> http://dotat.at/
ARDNAMURCHAN POINT TO CAPE WRATH INCLUDING THE OUTER HEBRIDES: VARIABLE 3 OR
LESS BECOMING EAST 3 OR 4, OCCASIONALLY 5 IN NORTH LATER. RAIN AT TIMES.
MODERATE OR GOOD. SLIGHT, OCCASIONALLY MODERATE IN NORTH.
David Adrien Tanguay
> (My argument is slightly weakened by the fact that most proposals for
> labeled break/continue use the existing label syntax, so there could
> *still* be a rogue goto somewhere else in the function. I'd advocate
> a distinct syntax if I could think of a good one.)
WSL (and some other language I can't remember) used the structure
"loop:label". Added to C, it would look like (e.g.):
while:a_label( cond ) ...
for:some_other_label( ... ) ...
--
David Tanguay http://www.sentex.ca/~datanguayh/
Kitchener, Ontario, Canada [43.24N 80.29W]
Kevin Bracey
Jonathan Coxhead <jona...@doves.demon.co.uk> wrote:
> Kevin Bracey wrote:
>
> > The arguments presented so far for leaving it seem to be:
> >
> > 1) An aversion to changing the standard.
> > 2) The harder labels are to use the better, because labels are bad.
> >
> > I don't agree with either argument. I'm strongly in favour of fixing the
> > grammar, and regard it as an oversight in C99.
>
> What about
>
> 3) It doesn't make sense to have a label after a declaration.
>
> ?
I assume you mean "a label before a declaration"?
> so it means that we don't have to worry about what happens if you jump
> "over" a declaration.
C90 already had a variant of that problem; you could do:
goto fred;
{
int blah = 3;
fred:
/* ...... */
}
C99 makes it worse, because you can do:
{
// .....
fred:
// .....
int blah = 3;
// .....
goto fred;
}
So labels can already occur before a declaration in the same block. This is
nasty, and C99 has to go to great pains to specify the initialisation and
lifetimes of the declared objects (including this differing for
variably-modified ones). It could have avoided this by taking the Algol 68
approach, but it's too late for that now.
So, allowing the label to be placed immediately before the label adds no new
issues. All the nasties have already been ruled upon.
David R Tribble
>> We don't need while loops either: ...
Oh, but it does add substance. The intent of a break statement with
a label is more obvious than the equivalent goto statement. Such a
construct adds *clarity*.
It's the same argument for having a 'for' construct instead of
using the equivalent 'while'. We added mixed statements and
declarations to C, yet that's nothing but syntactic sugar that can
be simulated with compound statements. There are many other examples.
It's simply a better way (more concise, clearer, cleaner, etc.) to
express a particular semantic action than what we currently have
available. It also has the virtue of expressing flow control semantics
without using the dreaded 'goto'.
As far as code bloat, I don't see how a labeled break/continue would
(or even could) result in code any different than that produced for
the equivalent 'goto' code.
Douglas A. Gwyn wrote:
> We're not discussing unrestrained use of goto, but
> rather the proposed labeled-break and equivalent
> that just happens to use goto. The point is, the
> difference is entirely a minor matter of syntax.
> Goto is already part of the language, so there is
> already a "just as good" way to code a labeled-
> break without adding redundant syntax.
"Just as good" is in the eye of the programmer. I think many would
agree that 'break xyz' is better than 'goto xyze' for reasons of
readibility. Some compiler writers might have other reasons to like it.
You could also argue that a program having break and continue
statements (labeled or not) but no goto statements is still a
goto-free program.
(FWIW, I use 'goto' as necessary, particularly for error recovery.
Languages without 'goto' are unduly crippled, in my opinion.)
-drt
David R Tribble
> My real question is not a plea for allowing it or something like that.
> I would like to know the historical reasons which prevented such labels
> from becoming allowed. I would be perfectly happy with a simple statement
> issue".
I suspect that *that* was the real reason. I further suspect that the
comparison of the C grammar to C++ was not that thorough, and so the
resulting syntax unintentionally suffers from this little restriction.
-drt
Eric Sosman
> Keith Thompson wrote:
>
>>>We don't need while loops either: ...
>
>
> Douglas A. Gwyn wrote:
>
>>True, but there is a significant difference in the
>>degree of code bloat in substituting the more basic
>>code for the fancier construct in the two cases.
>>In the case of labeled breaks, one needs the label
>>itself, some form of break directive along with the
>>name of the desired label, and punctuation. The
>>equivalent code I exhibited is about as small as
>>one could get away with, and is essentially the
>>same as was proposed (especially the version with
>>label at end of loop), except mine used a shorter
>>keyword. Therefore I have to ask again, what
>>purpose would be served by the proposed alternative?
>>It adds bulk but not substance.
>
>
> Oh, but it does add substance. The intent of a break statement with
> a label is more obvious than the equivalent goto statement. Such a
> construct adds *clarity*.
In the name of clarity, let's at least postpone adding
labelled break and continue to the language until somebody
dreams up a better way of expressing them than the absurd
way Java does. Really, now: A label to indicate where control
*doesn't* go?
True story: As a brand-newbie to Java I took the first
section of a Web-delivered course in the language. Even as
the said newbie, I spotted two substantive errors in the
course materials, and one of them had to do with the effect
of a labelled continue within a for loop. If the construct
is so confusing that professional course preparers can't get
it right, I submit that it's a poor construct.
... and in C, of course, it would be even more confusing
than in Java. Horrible thought:
label:
for (i = 0; i < 10; ++i) {
for (j = 0; j < 10; ++j) {
if (f(i,j))
break label;
if (g(i,j))
continue label;
if (h(i,j))
goto label;
}
}
Observe that each of the jumps transfers control to a different
location, despite the fact that all three apparently target the
same label. Madness!
Keith Thompson
[...]
> In the name of clarity, let's at least postpone adding
> labelled break and continue to the language until somebody
> dreams up a better way of expressing them than the absurd
> way Java does. Really, now: A label to indicate where control
> *doesn't* go?
I'm not familiar with the way Java does this. Is it similar to Perl
and Ada (languages I happen to be familiar with)?
> ... and in C, of course, it would be even more confusing
> than in Java. Horrible thought:
>
> label:
> for (i = 0; i < 10; ++i) {
> for (j = 0; j < 10; ++j) {
> if (f(i,j))
> break label;
> if (g(i,j))
> continue label;
> if (h(i,j))
> goto label;
> }
> }
>
> Observe that each of the jumps transfers control to a different
> location, despite the fact that all three apparently target the
> same label. Madness!
Of *course* they don't all transfer control to the same location; if
they did, they'd all be gotos. Nobody should expect "break" and
"continue" to be aliases for "goto".
I think the confusion results from thinking of the identifier at the
top of the loop as a label. Instead, think of it as the name of the
loop. It doesn't specify a single point to which control can be
transferred; it specifies the entire loop construct, just as a
function name refers to an entire function. (That's a good reason to
use a different syntax.)
Let's assume for the moment that we use a distinct syntax like
for:NAME (...;...;...) { ... }
Then your example, with an improved name for the loop, becomes:
for:OUTER (i = 0; i < 10; ++i) {
for (j = 0; j < 10; ++j) {
if (f(i,j))
break OUTER;
if (g(i,j))
continue OUTER;
if (h(i,j))
/* goto OUTER; */ /* this is now illegal */
}
}
That doesn't look so horrible to me.
Personally, I think I'd prefer a syntax where the loop name precedes
the "while", "for", or "do" keyword, so it stands out more. The most
obvious syntax
LABEL: for ...
is already taken for goto labels. The next most obvious syntax
LABEL:: for ...
is probably too similar to the goto label syntax, and would cause
tremendous confusion if the C++ folks ever picked this up.
The existing practice that I'm familiar with is:
Perl uses the same "LABEL:" syntax for both goto labels and loop
labels.
Ada uses "Label:" for loop and block labels, and <<LABEL>> for goto
labels (the latter is deliberately ugly).
Douglas A. Gwyn
> According to Douglas A. Gwyn <DAG...@null.net>:
>>Kevin Bracey wrote:
>>>... regard it as an oversight in C99.
>>No, labels on declarations have never been allowed in C.
I answered that. I could add, there is no need to
change it, as it would accomplish nothing that is
not readily supported using the existing language.
> ... In the absence of compelling reasons one way
> or the other, non-compelling reasons (e.g., aesthetics)
> should have prevailed.
Wrong.
> If I have one plea, then it is the following: amend the damn Rationale,
> it contains an incorrect example.
Agreed. The Rationale is a work-in-progress and is
intended to accurately reflect the standard, so I
am sure that it will be updated to fix the bogus
example. A semicolon could be added after the
label, for example, although probably we would use
cleaner code altogether.
Douglas A. Gwyn
> ... It also has the virtue of expressing flow control semantics
> without using the dreaded 'goto'.
That is a non-goal. The semantics are exactly the same.
One might think that it makes it *slightly* easier for
the compiler to detect this specific layout (presumably
to apply some special optimization), but if you think
about what the compiler code would be to do the test,
it's not appreciably easier.
> As far as code bloat, I don't see how a labeled break/continue would
> (or even could) result in code any different than that produced for
> the equivalent 'goto' code.
I was talking about the corresponding *C* source
code as exhibited in the article to which I was
directly responding.
> You could also argue that a program having break and continue
> statements (labeled or not) but no goto statements is still a
> goto-free program.
One needs to be more precise about what is meant and
why it might be desirable. There is a theorem that
says that if/goto is sufficient and that if/loop is
sufficient. The former if not used in a structured
way can impair source readability and hamper
optimization, but so can the latter (for different
reasons). The main theoretical advantage to the
latter is that there is *only one way out* of any
iteration, which makes it easier to verify wpc's
throughout the code. However, it in general forces
the introduction of additional flag variables,
which is a complication. The problem with using any
form of "break" or "continue" is that it creates
multiple paths out of an iteration, which makes the
code verification process more difficult.
> (FWIW, I use 'goto' as necessary, particularly for error recovery.
> Languages without 'goto' are unduly crippled, in my opinion.)
That is the canonical example of why goto is not
entirely a Bad Thing. One could dispense with goto
(for error handling, at any rate) if instead a good
exception handling mechanism is supported.
Keith Thompson
[...]
> > ... In the absence of compelling reasons one way
> > or the other, non-compelling reasons (e.g., aesthetics)
> > should have prevailed.
>
> Wrong.
No.
Keith Thompson
> > ... It also has the virtue of expressing flow control semantics
> > without using the dreaded 'goto'.
>
> That is a non-goal. The semantics are exactly the same.
> One might think that it makes it *slightly* easier for
> the compiler to detect this specific layout (presumably
> to apply some special optimization), but if you think
> about what the compiler code would be to do the test,
> it's not appreciably easier.
Yes, of course the semantics are exactly the same. The idea is to
allow the programmer to express his intent more clearly. It's not
about making things easier for compilers.
Different programmers have different preferences. The language
shouldn't cater to all of them, but it can certainly cater to some of
them. You certainly don't have to use labeled break/continue if you
don't want to, but I for one would like to see them in the language.
Doug, if the C language were being introduced today, and the
definition didn't include the break and continue statements, would you
object to a proposal to add them?
Douglas A. Gwyn
> Doug, if the C language were being introduced today, and the
> definition didn't include the break and continue statements, would you
> object to a proposal to add them?
That omits far too much context for me to provide an
accurate answer. Actually there is much I would do
differently from C if I were designing a new language.
Thomas Pornin
>
> I answered that.
Not really. You answered two other questions, that I did not ask:
1. are labels on declaration needed ?
2. should they be now allowed ?
I took great pain and a considerable amount of network bandwidth to
state clearly and unambiguously that these are NOT what I ask for.
I explained that when the interleaving was introduced, it would have
been easy to allow labels on declarations. As it has been pointed
out, all the problems that such labels would introduce (such as the
possibility to jump back before an array definition) had to be solved
for the interleaving itself. Whether the labels on declaration were
to be allowed or not was merely a matter of writing the grammar one
way or another, and that was it. It is absolutely true that labels on
declarations are not needed. But it is equally true that the absence of
such labels is not needed, either.
As for the two questions above, the answer to the first is clearly "no"
and nobody disputes that (but most find it irrelevant). The second
question I do not want to even consider because I know that it is a very
sensitive subject, prone to trigger long and bitter flamewars. And it
is NOT my purpose here.
--Thomas Pornin
Francis Glassborow
<DAG...@null.net> writes
>That is the canonical example of why goto is not
>entirely a Bad Thing. One could dispense with goto
>(for error handling, at any rate) if instead a good
>exception handling mechanism is supported.
Which reminds me of a student in an evening class I was giving many
years ago whose code was peppered with goto (not surprisingly he had
previously programmed in Basic). I thought I had explained the problem
to him and so was somewhat knocked back when he returned the following
week proudly proclaiming that he had found the correct C way to do it;
setjmp and longjmp :-(
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Dr A. N. Walker
Jonathan Coxhead <jona...@doves.demon.co.uk> wrote:
> What about
> 3) It doesn't make sense to have a label after a declaration.
Not really. Algol gets this partly right, but is also partly
a botch.
> ---a block ("unit", I think) was a sequence of
>statements-or-declarations (no labels allowed), followed by a sequence of
>possibly-labelled-statements.
In a serial clause, you can't label a statement until after
the last declaration. But you also can't label any statement in an
"enquiry clause" -- eg between "IF" and "THEN". This is to prevent
jumping back from a controlled clause into the controller, but makes
it quite hard to explain concisely what can be labelled. OTOH:
> This is to avoid cases like
> {
> if (f()) goto L0;
> int n = 3;
> L0:
> printf ("%d\n", n); // 3 or junk? Is n even declared at this point?
> }
would be [somewhat] OK in Algol. At that point, "n" would be properly
declared, but not initialised -- eg the 68G compiler delivers a run-time
fault on obeying the "print" statement in
( l0; INT n := 3; l0: print (n) )
>so it means that we don't have to worry about what happens if you jump "over" a
>declaration. A consequence is that you can never have a labelled declaration.
> (I hope I remembered that right from 20 years ago!)
Not quite. Jumping over declarations is not forbidden, and is
indeed sometimes [but not always, in somewhat arbitrary ways] a problem,
but jumping into them is impossible. More generally in Algol it is not
possible to jump "into" a construct, which is much more restrictive than
C, but perhaps better practice.
--
Andy Walker, School of MathSci., Univ. of Nott'm, UK.
a...@maths.nott.ac.uk
Chris Hills
<fra...@robinton.demon.co.uk> writes
>In article <luq*7w...@news.chiark.greenend.org.uk>, Tony Finch
><d...@dotat.at> writes
>>Chris Hills <ch...@phaedsys.org> wrote:
>>>
>>>What I can't understand is why is GNU different to ISO C in the first
>>>place? I would have thought that it would have been in the interest of
>>>the GNU crowd to have been compatible. I think part of the problem (from
>>>their point of view) is that the ISO C standard is not freely available
>>>(and free).
>>
>>When the GNU C extensions where created they didn't have anything to be
>>compatible with. C99 later extended the language in ways which are not
>>quite the same as GNU C, though there is a fair amount of overlap.
>
>And IIRC WG14 repeatedly asked the developers of GNU C for input about
>potential incompatibilities whilst C99 was under development.
What happened? Why did the GNU people not get involved?
>I remain slightly amused by the thesis that GNU C will become a de facto
>Standard whilst the same people decry MS's non-proprietary extensions to
>C. Why is one OK and the other not?
I was not decrying one but not the other. I was simply putting forward
the "GNU will be the standard" thesis for comment. Partly because I was
so surprised to hear it and interested in the reasons why it was
apparently going to take over the world...
The difference with the GNU "standard" is that it works for a lot more
platforms (including, apparently VAX, VMS and OS-2!) and processors from
(8-128bit) than the Win-OS does.
Personally I would rather ISO-C was the only standard as well as the
only Standard... At the moment we are in danger of having MC-C, GNU-C
and ISO-C.
I wonder how easy it would be to bring GNU-C back into line with ISO-C?
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills
<ja...@jacob.remcomp.fr> writes
>
>"Brian Inglis" <Brian....@SystematicSw.Invalid> a écrit dans le message
>de news:6befh05s1mqibb29d...@4ax.com...
>> On Mon, 9 Aug 2004 12:48:31 +0100 in comp.std.c, Francis Glassborow
>> What do you mean by MS *NON-proprietary* extensions to C?
>> Their compiler and library are proprietary products for a single
>> platform, and their license makes it illegal to reverse-engineer or
>> change them.
>
>I made lcc-win32 accept __declspec(dllexport), for instance,
>and nobody cares. You do not have to disassemble the compiler
>to use an extension...
>
>I do not even know if you can copyright
>__declspec()...
>
>Of course it would be better if the standard would not be
>gcc or msvc but a standard language definition. This discussion
>makes me believe that nobody really wants to develop the C language as
>such, not even the standards commitee. Let's get rid of C and concentrate
>on C++, the better C.
>
>This is really discouraging
Yes... very. See the other thread on C++ for the 8051... You do realise
that the vast majority of CPU's shipped are 8 bit systems where there is
no C++ compiler?
BTW there is more to it than a compiler, you need a complete HW debug
system often including an ICE.
Joseph Samuel Myers
Chris Hills <ch...@phaedsys.org> wrote:
>In article <8DtgOIOP...@robinton.demon.co.uk>, Francis Glassborow
><fra...@robinton.demon.co.uk> writes
>>potential incompatibilities whilst C99 was under development.
>
>What happened? Why did the GNU people not get involved?
When and where were the questions asked? I do not recall seeing any
such questions on the current public GCC (formerly EGCS) lists
<http://gcc.gnu.org/lists.html>, September 1997 onwards. I don't know
what might have happened on the old private invitation-only gcc2 list.
>I wonder how easy it would be to bring GNU-C back into line with ISO-C?
The general mood is against extensions and incompatibilities, but that
is not something that by itself causes changes to happen. The
standard answer applies:
http://gcc.gnu.org/faq.html#support
--
Joseph S. Myers
js...@gcc.gnu.org
James Kuyper
> I explained that when the interleaving was introduced, it would have
> been easy to allow labels on declarations. As it has been pointed
> out, all the problems that such labels would introduce (such as the
> possibility to jump back before an array definition) had to be solved
> for the interleaving itself. Whether the labels on declaration were
> to be allowed or not was merely a matter of writing the grammar one
> way or another, and that was it. It is absolutely true that labels on
> declarations are not needed. But it is equally true that the absence of
> such labels is not needed, either.
I thought the answer to your question was quite simple, obvious, and already
addressed. Such a change was simply not considered worth even the minimal amount
of effort required to make it. Emphasis on "not considered" - it's quite likely
that no one even thought about the issue.
David R Tribble
> I wonder how easy it would be to bring GNU-C back into line with ISO-C?
It appears to be a simple matter of time and effort:
http://gnuweb.binarycompass.org/software/gcc/gcc-3.0/c99status.html
-drt
Chris Hills
<fra...@robinton.demon.co.uk> writes
>In article <cf8gcv$fd0$1...@news-reader2.wanadoo.fr>, jacob navia
><ja...@jacob.remcomp.fr> writes
>>
>>gcc or msvc but a standard language definition. This discussion
>>makes me believe that nobody really wants to develop the C language as
>>such, not even the standards commitee. Let's get rid of C and concentrate
>>on C++, the better C.
>
>Library with a number of functions aimed at increasing security by
>reducing such things as buffer overruns.
MS is trying to produce a new Secure library that will include a large
amount of proprietary MS library stuff in it that is incompatible with
many other systems.
>Unlike Chris Hills,
You have no idea... :-)
> I meet regularly with the whole of WG14 (twice a
>year for five days at a time)
Yes. As convenor of your panel I send you to those meetings.
> as well as meeting individual members at
>other times.
really? You were complaining the other day you never meet any UK
experts. You only meet C experts when you go to the 2 WG14 meetings.
> I do not think that either the individuals or the companies
>the represent would support the view attributed to them or at least to a
>couple of unnamed members.
AFAIK They have both said it in front of you. However you are, as
usual, missing the point and turning it in to a personal vendetta. (and
you wonder why 75% of your own panel ignore you)
The point was about GNU becoming the de-facto standard. Not through any
political will or company manoeuvring but just happening. As I said I
was quite surprised at this. Also somewhat disappointed too. I would
prefer that ISO-C was THE standard, defacto and legally. I was simply
airing the proposal to see what other people thought.
Though I note there seems to be some comment that that was no liaison
with the GNU people. What I wonder is why they (GNU) did not track the
ISO standard. I don't think it is up to ISO panels to chase everyone who
is writing tools and compilers. Rather the tool and compiler writers to
track the standard
The MS debate is different as that is a specific company trying to get
their version of something as the standard. They are trying to include
a lot of their own proprietary stuff. BTW I note that VB is the defacto
standard whereas ISO-Basic is all but forgotten. I would not like to see
the same thing with C and Gnu-C.
>Indeed, I am very unhappy that such comments should be made by someone
>who is supposedly representing the BSI (or at least is convenor of its
>Panel for the C Standard).
I was speaking for my self. I don't recall in any of my posts claiming
to speak on behalf of or for any organisation. I have my own views and
I put those forward.
When I speak for a panel/committe/association I have no views. I give
the official view of the panel/committee/association.
You usually claim all sorts of things by association. (ie WG14 and
"knowing all the experts") You do however try to put words into other
peoples mouths quite often and attempt to link them to organisations.
For example in you post above
"
> I do not think that either the individuals or the companies
>the represent would support the view attributed to them
"
You are either wrong, as they have said this in front of you or you are
making comments in the air you have no real idea about. You are saying
two people you don't know would not have said it and their employers,
who you also don't know, also disapprove....
I speak for my self. It is you who brings BSI, one of my employers
(erroneously) and others into it. You may not be so happy if the company
you erroneously name decides to take action for you using their name
inappropriately.
Perhaps you should restrict yourself to speaking on behalf of yourself
and just that. Whilst you are member of the UK C panel (like many others
here) and you are also a member of WG14 (like many others here) you do
not speak for either yet you regularly claim association in your posts.
Speak for yourself and let others do likewise.
In any event please stick to the TECHNICAL arguments. The point under
discussion was:-
That GNU-C was not the same as ISO-C and that by default GNU-C would
eventually become the de-facto standard. this is because commercial
compilers would start tracking the GNU-C "standard" rather than ISO-C
What I can't understand is why GNU-C is different from ISO-C in the
first place.... One of the reasons is possibly the fact that all the
GNU stuff is free and they GNU people hate paying for things. They may
have been using K&R and old committee drafts for their guides rather
than the official chargeable version.
Regards
Chris
Francis Glassborow
<ch...@phaedsys.org> writes
>What I can't understand is why GNU-C is different from ISO-C in the
>first place.... One of the reasons is possibly the fact that all the
>GNU stuff is free and they GNU people hate paying for things. They may
>have been using K&R and old committee drafts for their guides rather
>than the official chargeable version.
For about the same reason that MS C often has extensions. Unfortunately
GNU C added a number of extensions that were similar to but not
identical to those later added to C99. I believe that a great deal of
work is currently being done to making GNU C conform to C99 when in a
strictly conforming mode. Of course that does not prevent some
programmers being enthusiastic about using such things as nested
functions.
As a distributed organisation without funds it is hard for them to have
a representative attend WG14 meetings.
Some people are very fond of complaining about Microsoft failing to
conform to Standards when they meet their customers needs but seem to
think it is not a problem when others do the same.
BTW, one of the features of libraries is that they implicitly do not
break existing code as long as they use different names, and in the case
of C confine those names to new header files. Another feature of the
Secure Library proposals is that the work on them has been done by an
outside consultant.
Perhaps you would like to provide evidence that they contain MS
proprietary material (and even if it did, turning it into a TR
effectively makes that material non-proprietary).
And why is the IBM Decimal float proposal OK (aimed at providing direct
support for IBM hardware) and MS Secure Library proposals not?
Chris Hills
<fra...@robinton.demon.co.uk> writes
>In article <LamQVbA42PIBFA$l...@phaedsys.demon.co.uk>, Chris Hills
><ch...@phaedsys.org> writes
>>What I can't understand is why GNU-C is different from ISO-C in the
>>first place.... One of the reasons is possibly the fact that all the
>>GNU stuff is free and they GNU people hate paying for things. They may
>>have been using K&R and old committee drafts for their guides rather
>>than the official chargeable version.
>
>For about the same reason that MS C often has extensions.
That is not the case. MS has extensions for MS Windows. GNU doesn't it
runs on many systems that don't have an OS.
> Unfortunately
>GNU C added a number of extensions that were similar to but not
>identical to those later added to C99. I believe that a great deal of
>work is currently being done to making GNU C conform to C99 when in a
>strictly conforming mode.
Is there anyone who is a GNu implementer who can comment?
> Of course that does not prevent some
>programmers being enthusiastic about using such things as nested
>functions.
Nothing prevents "enthusiastic programmers" from creating mess from
anything. Even SPARC Ada :-)
>As a distributed organisation without funds it is hard for them to have
>a representative attend WG14 meetings.
They don't need to have anyone on WG14.... all members of WG14 are
members of a National body. There are GNU implimentors on your National
Body. There have been for some years.
>Some people are very fond of complaining about Microsoft failing to
>conform to Standards when they meet their customers needs but seem to
>think it is not a problem when others do the same.
It is a problem who ever does it. BTW there is a damned good book on the
SW industry called "In Search of Stupidity" about the rise and fall of
software companies. Fascinating!
>BTW, one of the features of libraries is that they implicitly do not
>break existing code as long as they use different names, and in the case
>of C confine those names to new header files.
I came across some code the other day where the "consultant" reused a
whole load of the standard library names.... It may have been on an
automotive system.
> Another feature of the
>Secure Library proposals is that the work on them has been done by an
>outside consultant.
So what?
>Perhaps you would like to provide evidence that they contain MS
>proprietary material
The presentation MS gave on the subject. They mention the standard
library + Ms extensions some 2000 functions.
> (and even if it did, turning it into a TR
>effectively makes that material non-proprietary).
Thus making the MS library the standard?
>And why is the IBM Decimal float proposal OK (aimed at providing direct
>support for IBM hardware) and MS Secure Library proposals not?
Because some one is going to have to interface C to the HW. It is better
done inside the ISO language than outside.
Also once the interface is defined other people implementing decimal
maths on other HW have a standard to work to.
If MS were simply doing a secure version of the standard library I would
not mind but the are wrapping in a lot of other stuff that is not part
of the normal library.
Chris Hills
<fra...@robinton.demon.co.uk> writes
>In article <LamQVbA42PIBFA$l...@phaedsys.demon.co.uk>, Chris Hills
><ch...@phaedsys.org> writes
>>What I can't understand is why GNU-C is different from ISO-C in the
>>first place.... One of the reasons is possibly the fact that all the
>>GNU stuff is free and they GNU people hate paying for things. They may
>>have been using K&R and old committee drafts for their guides rather
>>than the official chargeable version.
>
>a representative attend WG14 meetings.
Actually Francis, you have already been answered on this point by a
member of WG14 who has also been a member of your national panel for
some years....
Can you clarify when the GNU people were involved?
Perhaps we should look at ways of bringing GNU back in line with ISO C?
In article <cfglr1$hkb$1...@pegasus.csx.cam.ac.uk>, Joseph Samuel Myers
<js...@cam.ac.uk> writes
>In article <qu3YInAE...@phaedsys.demon.co.uk>,
>Chris Hills <ch...@phaedsys.org> wrote:
>>In article <8DtgOIOP...@robinton.demon.co.uk>, Francis Glassborow
>><fra...@robinton.demon.co.uk> writes
>>>And IIRC WG14 repeatedly asked the developers of GNU C for input about
>>>potential incompatibilities whilst C99 was under development.
>>
>>What happened? Why did the GNU people not get involved?
>
>When and where were the questions asked? I do not recall seeing any
>such questions on the current public GCC (formerly EGCS) lists
><http://gcc.gnu.org/lists.html>, September 1997 onwards. I don't know
>what might have happened on the old private invitation-only gcc2 list.
>
>>I wonder how easy it would be to bring GNU-C back into line with ISO-C?
>
>The general mood is against extensions and incompatibilities, but that
>is not something that by itself causes changes to happen. The
>standard answer applies:
>
>http://gcc.gnu.org/faq.html#support
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
David Hopwood
> Perhaps you would like to provide evidence that [Strsafe.h] contains
> MS proprietary material (and even if it did, turning it into a TR
> effectively makes that material non-proprietary).
It depends on Windows-specific types such as TCHAR, LPTSTR, HRESULT, etc.
That's too much to pull into the C standard library.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/strsafe.asp
David Hopwood <david.nosp...@blueyonder.co.uk>
Douglas A. Gwyn
> MS is trying to produce a new Secure library that will include a large
> amount of proprietary MS library stuff in it that is incompatible with
> many other systems.
No, that is a complete mischaracterization.
> What I can't understand is why GNU-C is different from ISO-C in the
> first place....
I think you need to specify more precisely what is meant
by that. Certainly I have had no problem using strictly
conforming (1989) Standard C source code with GNU C
compilers, to the limited extent that I've used them
(mainly for cross-compiling for embedded systems). I
understand that there are some new features added by the
1999 C standard that are not yet implemented in GNU C,
but that is also true of several other compilers. There
are a large number of GCC compiler options that produce
differing behavior, largely for purposes of matching the
behavior of older compilers. Also, GNU added some
extensions to C that were later standardized with
somewhat different characteristics, causing (for users
of GNU extensions) a compatibility problem. Some GNU C
developers have indicated that they have as one goal
eventual conformance to the full 1999 C standard. The
situation seems better now than it was some 15 years ago,
when there was more of a NIH syndrome and lack of
appreciation for the value of language standardization.
Douglas A. Gwyn
> <fra...@robinton.demon.co.uk> writes
>>Perhaps you would like to provide evidence that they contain MS
>>proprietary material
> The presentation MS gave on the subject. They mention the standard
> library + Ms extensions some 2000 functions.
What in the world are you talking about?
Microsoft's presentation, asking use to consider
improvements to standard C library interfaces in
order to prevent buffer overruns and accidental
reuse of static internal buffers (for example),
was WG14 N1007. Randy Meyers in WG14 N1031 had
a similar, more detailed proposal. A Work Item
request was submitted to allow us to tackle this
area. Nobody, Microsoft included, has suggested
that WG14 adopt the full extended Microsoft C
library; we're only considering safer analogues
of the current standard C library functions.
Francis Glassborow
>In article <ZX3praGQ...@robinton.demon.co.uk>, Francis Glassborow
><fra...@robinton.demon.co.uk> writes
>>In article <LamQVbA42PIBFA$l...@phaedsys.demon.co.uk>, Chris Hills
>><ch...@phaedsys.org> writes
>>>What I can't understand is why GNU-C is different from ISO-C in the
>>>first place.... One of the reasons is possibly the fact that all the
>>>GNU stuff is free and they GNU people hate paying for things. They may
>>>have been using K&R and old committee drafts for their guides rather
>>>than the official chargeable version.
>>
>>As a distributed organisation without funds it is hard for them to have
>>a representative attend WG14 meetings.
>
>
>Actually Francis, you have already been answered on this point by a
>member of WG14 who has also been a member of your national panel for
>some years....
So...? Not everyone round here knows about that or the answer.
>
>Can you clarify when the GNU people were involved?
During the work on C99, to the best of my knowledge they weren't but
during much of that time I was unable to attend WG14 meetings because
they were held at different times and at different locations to the C++
ones. The UK already had excellent representatives on WG14 so I did my
best to contribute to WG21, which had much more work to do.
>
>Perhaps we should look at ways of bringing GNU back in line with ISO C?
And every other major C implementation? IIUC they are already working
hard to ensure that GNU C conforms in its 'conforming' mode. But it does
not seem to me to be the business of WG14.
Francis Glassborow
Hopwood <david.nosp...@blueyonder.co.uk> writes
>Francis Glassborow wrote:
>> Perhaps you would like to provide evidence that [Strsafe.h] contains
>> MS proprietary material (and even if it did, turning it into a TR
>>effectively makes that material non-proprietary).
>
>It depends on Windows-specific types such as TCHAR, LPTSTR, HRESULT, etc.
>That's too much to pull into the C standard library.
Have you read N1031? Or its precursor, N1007? Those are the proposals on
the table. They may be motivated by MS's proprietary secure functions
library but they are concerned entirely with perfectly Standard features
of C. MS have never, AFAIK, proposed that their own library be
standardised.
Now I wonder how many other people have formed opinions on this work
item without reading N1007 and N1031. When Joe Public does that it is
understandable but if a NB representative did so I do not think I would
be the only one to feel some concern.
Brian Inglis
<ch...@phaedsys.org> wrote:
>In article <ZX3praGQ...@robinton.demon.co.uk>, Francis Glassborow
><fra...@robinton.demon.co.uk> writes
>>In article <LamQVbA42PIBFA$l...@phaedsys.demon.co.uk>, Chris Hills
>><ch...@phaedsys.org> writes
>>>What I can't understand is why GNU-C is different from ISO-C in the
>>>first place.... One of the reasons is possibly the fact that all the
>>>GNU stuff is free and they GNU people hate paying for things. They may
>>>have been using K&R and old committee drafts for their guides rather
>>>than the official chargeable version.
>>
>>For about the same reason that MS C often has extensions.
>
>That is not the case. MS has extensions for MS Windows. GNU doesn't it
>runs on many systems that don't have an OS.
>
>> Unfortunately
>>GNU C added a number of extensions that were similar to but not
>>identical to those later added to C99. I believe that a great deal of
>>work is currently being done to making GNU C conform to C99 when in a
>>strictly conforming mode.
>
>Is there anyone who is a GNu implementer who can comment?
Not me, but see:
<URL:http://gcc.gnu.org/c99status.html>
<URL:http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/CONFORMANCE?rev=1.10&content-type=text/x-cvsweb-markup&cvsroot=glibc>
Summary:
GCC has some issues with the library, and glibc has some issues
requiring compiler support before they can implement the library.
Where gcc status indicates Done, C99 support appears to be complete,
whereas status Broken indicates that gcc support for the feature has
differences from or has not been checked to conform to the standard,
not that the feature does not work.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
Clive D. W. Feather
<david.nosp...@blueyonder.co.uk> writes
>> 6.8p3:
>> The initializers of objects that have automatic storage
[...]
>This is a little sloppily worded; I would have thought that each time
>the declaration is reached would create a new object, not just store
>a value in the same object.
No. When the block associated with the scope of the identifier is
entered, the object is created. When the declaration is reached, the
object is initialized.
> int *p;
> int i;
> for (i = 0; i < 10; i++) {
> int x = i;
> if (i > 0) printf("%d", *p);
> p = &x;
> }
>
>have undefined behaviour?
Yes.
>(I think it does, since there are 10 different
>x objects, and the previous &x has gone out of scope on each iteration.)
Correct; each x is initialized once.
The loop part of the code is equivalent in effect to:
for (i = 0; i < 10; i++) {
__create(int, x);
x = i;
if (i > 0) printf("%d", *p);
p = &x;
__destroy(x); // Hence p holds an unusable value
}
Now look at this code:
int *p;
int i;
{
i = 0;
loop:
int x = i, y;
if (i > 0) printf ("%d", *p);
p = &x;
y = i;
if (i++ < 10) goto loop;
}
The text you quoted says that the compound statement of that code is
equivalent to the C90 code:
{
int x, y;
i = 0;
loop:
x = i, y = __indeterminate;
if (i > 0) printf ("%d", *p);
p = &x;
y = i;
if (i++ < 10) goto loop;
}
and has the effect:
{
__create(int, x);
__create(int, y);
i = 0;
loop:
x = i, y = __indeterminate;
if (i > 0) printf ("%d", *p);
p = &x;
y = i;
if (i++ < 10) goto loop;
__destroy(x);
__destroy(y);
}
Therefore the code *is* legitimate.
--
Clive D.W. Feather | Home: <cl...@davros.org>
Tel: +44 20 8495 6138 (work) | Web: <http://www.davros.org>
Fax: +44 870 051 9937 | Work: <cl...@demon.net>
Please reply to the Reply-To address, which is: <cl...@davros.org>
Clive D. W. Feather
<DAG...@null.net> writes
>> We don't need while loops either: ...
>True, but there is a significant difference in the
>degree of code bloat in substituting the more basic
>code for the fancier construct in the two cases.
[...]
>Therefore I have to ask again, what
>purpose would be served by the proposed alternative?
>It adds bulk but not substance.
If it is done correctly - so that you can't "goto" the label of the loop
- it adds security: the construct can't be misused deliberately or by
accident.