By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,383 Members | 2,002 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,383 IT Pros & Developers. It's quick & easy.

Reason for ISO ; warning

P: n/a
[Warning] ISO C does not allow extra ';' outside of a function

int n;;

int main(void)
{
....
}

Anyone care to enlighten me as to why ISO C does not allow this, but
apparently ANSI c99 does?

Ta

Dec 7 '05 #1
Share this Question
Share on Google+
22 Replies


P: n/a
pemo wrote:

[Warning] ISO C does not allow extra ';' outside of a function

int n;;
That's an object definition,
followed by what looks like an empty statement.

int main(void)
{
...
}

Anyone care to enlighten me as to why ISO C does not allow this,
Statements are only allowed inside of function definitions.
but apparently ANSI c99 does?


I don't know so much about C99.

--
pete
Dec 7 '05 #2

P: n/a
pemo said:
[Warning] ISO C does not allow extra ';' outside of a function

int n;;

int main(void)
{
...
}

Anyone care to enlighten me as to why ISO C does not allow this,
It's the grammar. I presume you mean C90, because...
but apparently ANSI c99 does?


....here you mean ISO C99. ANSI didn't ratify the revised Standard until
2000, so it's ANSI C2000 or, if you prefer, ANSI C00.

I wasn't aware that executable code was allowed outside a function in C99.
C&V?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Dec 7 '05 #3

P: n/a
Richard Heathfield wrote:
I wasn't aware that executable code was
allowed outside a function in C99.
C&V?


External definitions of objects are executable code.

--
pete
Dec 7 '05 #4

P: n/a

"pete" <pf*****@mindspring.com> wrote in message
news:43**********@mindspring.com...
pemo wrote:

[Warning] ISO C does not allow extra ';' outside of a function

int n;;


That's an object definition,
followed by what looks like an empty statement.

int main(void)
{
...
}

Anyone care to enlighten me as to why ISO C does not allow this,


Statements are only allowed inside of function definitions.


Yes, that makes sense - ta.
Dec 7 '05 #5

P: n/a

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:dn**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...
pemo said:
[Warning] ISO C does not allow extra ';' outside of a function

int n;;

int main(void)
{
...
}

Anyone care to enlighten me as to why ISO C does not allow this,


It's the grammar. I presume you mean C90, because...
but apparently ANSI c99 does?


...here you mean ISO C99. ANSI didn't ratify the revised Standard until
2000, so it's ANSI C2000 or, if you prefer, ANSI C00.

I wasn't aware that executable code was allowed outside a function in C99.
C&V?


Interesting!
It's the grammar. I presume you mean C90


'I' didn't come into it Richard, the message came from gcc and appears
with -Wall -pedantic -std=c99

So, I assume c99 is what you're caling c00?
Dec 7 '05 #6

P: n/a
pemo wrote:
"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:dn**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...
pemo said:
but apparently ANSI c99 does?
^^^^
This bit

...here you mean ISO C99. ANSI didn't ratify the revised Standard until
2000, so it's ANSI C2000 or, if you prefer, ANSI C00.

<snip>


'I' didn't come into it Richard, the message came from gcc and appears
with -Wall -pedantic -std=c99

So, I assume c99 is what you're caling c00?


That gcc option means ISO C99, there is no ANSI C99, which seems to be
what R Heathfield was getting at.

--
imalone
Dec 7 '05 #7

P: n/a

"Ian Malone" <ib***@cam.ac.uk> wrote in message
news:43**************@cam.ac.uk...
pemo wrote:
"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:dn**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...
pemo said:

but apparently ANSI c99 does? ^^^^
This bit

...here you mean ISO C99. ANSI didn't ratify the revised Standard until
2000, so it's ANSI C2000 or, if you prefer, ANSI C00.


<snip>


'I' didn't come into it Richard, the message came from gcc and appears
with -Wall -pedantic -std=c99

So, I assume c99 is what you're caling c00?


That gcc option means ISO C99, there is no ANSI C99, which seems to be
what R Heathfield was getting at.


Ah, ok, so is -ansi the ANSI variant then?
Dec 7 '05 #8

P: n/a
pemo said:
the message came from gcc and appears
with -Wall -pedantic -std=c99
Despite the flag name, gcc does not fully support C99.
So, I assume c99 is what you're caling c00?


If you mean the ISO C Standard, it's C99. If you mean the ANSI C Standard,
it's C00.

1989: ANSI C (C89).
1990: ISO C (C90) - this is effectively identical to C89, the only changes I
know about being section number changes.
1995: There was a minor mod to the Standard which, I believe, was adopted by
both ISO and ANSI.
1999: ISO C (C99).
2000: ANSI C (C00 or C2000) - this is effectively identical to C99.

Most people use C89 when they mean either C89 or C90, and C99 when they mean
either C99 or C00/C2000 - despite the fact that C89 refers to the ANSI
Standard and C99 refers to the ISO Standard.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Dec 7 '05 #9

P: n/a
In article <dn**********@news.ox.ac.uk>, pemo <us***********@gmail.com> wrote:
Anyone care to enlighten me as to why ISO C does not allow this, but
apparently ANSI c99 does?


Ignoring the question of what ANSI c99 is, what makes you think that it
allows it?

When GCC says that ISO C does not allow something, it probably means
that GCC allows it as an extension, not that some ANSI C version
allows it.

-- Richard
Dec 7 '05 #10

P: n/a
In article <dn**********@news.ox.ac.uk>, pemo <us***********@gmail.com> wrote:
Ah, ok, so is -ansi the ANSI variant then?


There isn't an "ANSI variant". ANSI standardised C in 1989. ISO
adopted that definition in 1990. ISO produced another standard in
1999, which (apparently) ANSI adopted in 2000. So ANSI C is the same
as ISO C, and the versions can be referred to as C89 and C00 or C90
and C99 depending on which standards body you prefer.

-- Richard
Dec 7 '05 #11

P: n/a
Ian Malone said:
That gcc option means ISO C99, there is no ANSI C99, which seems to be
what R Heathfield was getting at.


Sorry I wasn't clear. I was actually trying to get two points across at the
same time, always a bad idea.

The first point was that the C99 switch in gcc is a bit optimistic. gcc does
not fully support the new Standard, no matter what you choose to call it.

The second point was about what you choose to call it!, and that has now
been explained ad nauseam.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Dec 7 '05 #12

P: n/a

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> wrote in message
news:dn**********@pc-news.cogsci.ed.ac.uk...
In article <dn**********@news.ox.ac.uk>, pemo <us***********@gmail.com>
wrote:
Ah, ok, so is -ansi the ANSI variant then?


There isn't an "ANSI variant". ANSI standardised C in 1989. ISO
adopted that definition in 1990. ISO produced another standard in
1999, which (apparently) ANSI adopted in 2000. So ANSI C is the same
as ISO C, and the versions can be referred to as C89 and C00 or C90
and C99 depending on which standards body you prefer.


Sorry, not what I meant as a question [my fault], it was more what -ansi
*means* as a gcc switch.

OT here of course, but for completeness - here's what the manual says...

The original ANSI C standard (X3.159-1989) was ratified in 1989 and
published in 1990.
This standard was ratified as an ISO standard (ISO/IEC 9899:1990) later in
1990. There
were no technical differences between these publications, although the
sections of the ANSI
standard were renumbered and became clauses in the ISO standard. This
standard, in
both its forms, is commonly known as C89, or occasionally as C90, from the
dates of
ratification. The ANSI standard, but not the ISO standard, also came with a
Rationale
document. To select this standard in GCC, use one of the options '-ansi',
'-std=c89' or
'-std=iso9899:1990';
Dec 7 '05 #13

P: n/a
On 2005-12-07 11:22:27 -0500, "pemo" <us***********@gmail.com> said:

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> wrote in message
news:dn**********@pc-news.cogsci.ed.ac.uk...
In article <dn**********@news.ox.ac.uk>, pemo <us***********@gmail.com> wrote:
Ah, ok, so is -ansi the ANSI variant then?


There isn't an "ANSI variant". ANSI standardised C in 1989. ISO
adopted that definition in 1990. ISO produced another standard in
1999, which (apparently) ANSI adopted in 2000. So ANSI C is the same
as ISO C, and the versions can be referred to as C89 and C00 or C90
and C99 depending on which standards body you prefer.


Sorry, not what I meant as a question [my fault], it was more what
-ansi *means* as a gcc switch.

OT here of course, but for completeness - here's what the manual says...

The original ANSI C standard (X3.159-1989) was ratified in 1989 and
published in 1990.
This standard was ratified as an ISO standard (ISO/IEC 9899:1990) later
in 1990. There
were no technical differences between these publications, although the
sections of the ANSI
standard were renumbered and became clauses in the ISO standard. This
standard, in
both its forms, is commonly known as C89, or occasionally as C90, from
the dates of
ratification. The ANSI standard, but not the ISO standard, also came
with a Rationale
document. To select this standard in GCC, use one of the options
'-ansi', '-std=c89' or
'-std=iso9899:1990';


Well, the manual just told you; '-ansi' means the same as '-std=c89' or
'-std=iso9899:1990'

--
Clark S. Cox, III
cl*******@gmail.com

Dec 7 '05 #14

P: n/a

"Clark S. Cox III" <cl*******@gmail.com> wrote in message
news:2005120711335216807-clarkcox3@gmailcom...
On 2005-12-07 11:22:27 -0500, "pemo" <us***********@gmail.com> said:

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> wrote in message
news:dn**********@pc-news.cogsci.ed.ac.uk...
In article <dn**********@news.ox.ac.uk>, pemo <us***********@gmail.com>
wrote:
Ah, ok, so is -ansi the ANSI variant then?

There isn't an "ANSI variant". ANSI standardised C in 1989. ISO
adopted that definition in 1990. ISO produced another standard in
1999, which (apparently) ANSI adopted in 2000. So ANSI C is the same
as ISO C, and the versions can be referred to as C89 and C00 or C90
and C99 depending on which standards body you prefer.


Sorry, not what I meant as a question [my fault], it was more what -ansi
*means* as a gcc switch.

OT here of course, but for completeness - here's what the manual says...

The original ANSI C standard (X3.159-1989) was ratified in 1989 and
published in 1990.
This standard was ratified as an ISO standard (ISO/IEC 9899:1990) later
in 1990. There
were no technical differences between these publications, although the
sections of the ANSI
standard were renumbered and became clauses in the ISO standard. This
standard, in
both its forms, is commonly known as C89, or occasionally as C90, from
the dates of
ratification. The ANSI standard, but not the ISO standard, also came with
a Rationale
document. To select this standard in GCC, use one of the options '-ansi',
'-std=c89' or
'-std=iso9899:1990';


Well, the manual just told you; '-ansi' means the same as '-std=c89' or
'-std=iso9899:1990'


Um, yeah, I noticed! But thanks for pointing it out.
Dec 7 '05 #15

P: n/a
"pemo" <us***********@gmail.com> writes:
[Warning] ISO C does not allow extra ';' outside of a function

int n;;

int main(void)
{
...
}

Anyone care to enlighten me as to why ISO C does not allow this, but
apparently ANSI c99 does?


If "int n;;" appeared inside a function, it would be a declaration
"int n;" followed by an empty statement ";". Since the grammar
doesn't allow statements outside functions, "int n;;" outside a
function is an error.

As far as I know, this didn't change between C90 and C99; gcc seems to
agree:

% cat tmp.c
int x;;
% gcc --version | head -1
gcc (GCC) 4.0.2
% gcc -c -pedantic -std=c89 tmp.c
tmp.c:1: warning: ISO C does not allow extra ';' outside of a function
% gcc -c -pedantic -std=iso9899:1990 tmp.c
tmp.c:1: warning: ISO C does not allow extra ';' outside of a function
% gcc -c -pedantic -std=iso9899:199409 tmp.c
tmp.c:1: warning: ISO C does not allow extra ';' outside of a function
% gcc -c -pedantic -std=c99 tmp.c
tmp.c:1: warning: ISO C does not allow extra ';' outside of a function
% gcc -c -pedantic -std=c9x tmp.c
tmp.c:1: warning: ISO C does not allow extra ';' outside of a function
% gcc -c -pedantic -std=iso9899:1999 tmp.c
tmp.c:1: warning: ISO C does not allow extra ';' outside of a function
% gcc -c -pedantic -std=iso9899:1999 tmp.c
tmp.c:1: warning: ISO C does not allow extra ';' outside of a function

--
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.
Dec 7 '05 #16

P: n/a
On Wed, 7 Dec 2005 15:48:53 +0000 (UTC), Richard Heathfield
<in*****@invalid.invalid> wrote in comp.lang.c:
pemo said:
the message came from gcc and appears
with -Wall -pedantic -std=c99


Despite the flag name, gcc does not fully support C99.
So, I assume c99 is what you're caling c00?


If you mean the ISO C Standard, it's C99. If you mean the ANSI C Standard,
it's C00.

1989: ANSI C (C89).
1990: ISO C (C90) - this is effectively identical to C89, the only changes I
know about being section number changes.
1995: There was a minor mod to the Standard which, I believe, was adopted by
both ISO and ANSI.
1999: ISO C (C99).
2000: ANSI C (C00 or C2000) - this is effectively identical to C99.

Most people use C89 when they mean either C89 or C90, and C99 when they mean
either C99 or C00/C2000 - despite the fact that C89 refers to the ANSI
Standard and C99 refers to the ISO Standard.


Sheesh, you are not only beating a dead horse, you are beating it
incorrectly. The ANSI delegation to ISO voted to ratify the 1999
version of the C standard at the same time that all other the member
national standard bodies, except for the British who voted against it,
did.

Due to a procedural issue, meaning somebody at ANSI objected,
ratification as an American National Standard required sending it out
to their members as a vote. It was officially approved as an American
National Standard on May 15, 2000.

Nevertheless, if you point your favorite browser to:

http://webstore.ansi.org/ansidocstor...EC+9899%2D1999

....you will see that for the princely sum of $18.00USD, you can still
purchase:

Document#: INCITS/ISO/IEC 9899-1999
Title: Programming Languages - C (formerly ANSI/ISO/IEC
9899-1999)

The delay in ANSI approval as an American National Standard did not in
any way change the date. ANSI C99 is "ANSI C99", not "ANSI C00" or
"ANSI C2000". In fact, ANSI doesn't even call it an "ANSI" standard
anymore.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Dec 8 '05 #17

P: n/a
Jack Klein said:
On Wed, 7 Dec 2005 15:48:53 +0000 (UTC), Richard Heathfield
<in*****@invalid.invalid> wrote in comp.lang.c:
Most people use C89 when they mean either C89 or C90, and C99 when they
mean either C99 or C00/C2000 - despite the fact that C89 refers to the
ANSI Standard and C99 refers to the ISO Standard.
Sheesh, you are not only beating a dead horse,


It's what we do here. :-)
you are beating it incorrectly.


That's more serious. Since you know far more about this than I do, I'm happy
to accept the correction and apologise for supplying misinformation.

Just out of curiosity, what's the right way to beat a dead horse?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Dec 8 '05 #18

P: n/a
Richard Heathfield wrote:
<snip> I wasn't aware that executable code was allowed outside a function in C99.
C&V?


not the standart, but the C99 Rationale:

<quote>
5.1.2 Execution Environments

The definition of program startup in the Standard is designed to permit
initialization of static
storage by executable code, as well as by data translated into the program image.
</quote>

so this should be valid (and compiles with -Wall -pedantic -std=c99):

#include <string.h>

size_t blah = strlen("abc");

/*...*/
Dec 8 '05 #19

P: n/a
Wolfgang Riedel wrote:
so this should be valid (and compiles with -Wall -pedantic -std=c99):

#include <string.h>

size_t blah = strlen("abc");

/*...*/


It's not valid, and gcc produces the diagnostic message "initializer
element is not constant" when compiled with exactly the options you give.

--
Simon.
Dec 8 '05 #20

P: n/a
Simon Biber wrote:

Wolfgang Riedel wrote:
so this should be valid
(and compiles with -Wall -pedantic -std=c99):

#include <string.h>

size_t blah = strlen("abc");

/*...*/


It's not valid, and gcc produces the diagnostic message "initializer
element is not constant"
when compiled with exactly the options you give.


C99
6.7.8 Initialization

[#4] All the expressions in an initializer for an object
that has static storage duration shall be constant
expressions or string literals.

6.6 Constant expressions

[#7] More latitude is permitted for constant expressions in
initializers. Such a constant expression shall be, or
evaluate to, one of the following:
-- an arithmetic constant expression,
-- a null pointer constant,
-- an address constant, or
-- an address constant for an object type plus or minus an
integer constant expression.

[#8] An arithmetic constant expression shall have arithmetic
type and shall only have operands that are integer
constants, floating constants, enumeration constants,
character constants, and sizeof expressions.

--
pete
Dec 8 '05 #21

P: n/a
Simon Biber wrote:

Wolfgang Riedel wrote:
so this should be valid (and compiles with -Wall -pedantic -std=c99):

#include <string.h>

size_t blah = strlen("abc");

/*...*/


It's not valid, and gcc produces the diagnostic message "initializer
element is not constant" when compiled with exactly the options you give.

--
Simon.


You snipped the rationale, I quoted.
I think it's correct (evaluates to arithmetic constant exrpssion).

Btw. my gcc doesn't warn (maybe not the latest & greatest):
gcc --version

gcc (GCC) 3.2.2
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

cat z2.c && gcc -Wall -pedantic -std=c99 -o z2 z2.c && echo $? && ./z2

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static int bah = strlen("abc");
int
main(void)
{
printf("%d\n", bah);
exit(0);
}
0
3
Dec 8 '05 #22

P: n/a
Wolfgang Riedel wrote:
Simon Biber wrote:
Wolfgang Riedel wrote:
so this should be valid (and compiles with -Wall -pedantic -std=c99):

#include <string.h>

size_t blah = strlen("abc");

/*...*/ It's not valid, and gcc produces the diagnostic message "initializer
element is not constant" when compiled with exactly the options you give.

--
Simon.


You snipped the rationale, I quoted.
I think it's correct (evaluates to arithmetic constant exrpssion).

No. The relevant definition is

"An arithmetic constant expression shall have arithmetic type and shall only
have operands that are integer constants, floating constants, enumeration
constants, character constants, and sizeof expressions. Cast operators in an
arithmetic constant expression shall only convert arithmetic types to
arithmetic types, except as part of an operand to a sizeof operator whose
result is an integer constant."

'strlen("abc")' doesn't qualify. gcc is free to evaluate 'strlen("abc")' as
a constant expression, but this does not make it an arithmetic constant
expression. Of course, the initializer to "blah" need only be a constant
expression. It doesn't have to be an arithmetic constant expression
specifically.
Btw. my gcc doesn't warn (maybe not the latest & greatest):

<snip>
Not a bug. Later versions of gcc do warn because standards-conforming
compilers are not required to accept the program, but gcc does not violate
the standard by not issuing a diagnostic -- implementations are expressly
allowed to accept other forms of expressions as constant than the ones
described by the standard.

If you expect 'strlen("abc")' to be a constant expression, you're relying on
an extension. It's not portable code.

Note that gcc does *not* allow expressions that cannot be evaluated at
compile time as initializers, and rightly so. This will not compile:

size_t foo();
size_t blah = foo();

S.
Dec 8 '05 #23

This discussion thread is closed

Replies have been disabled for this discussion.