Sigh. It's been awhile since I've programmed in C, but I'm SURE that
you can have a function whose scope is purely within another function.
Yet here I have a program which compiles without a peep under gcc4.2.1
(with -ansi -Wall, no less), AND runs correctly, but which icc
(10.1.015) won't touch with a ten-foot-pole:

=====begin sample program=====
#include <stdio.h>

int main()
{
int sub1()
{
printf("1");
return(0);
}
int sub2()
{
printf("2\n");
return(0);
}
/* start of main */
sub1();
sub2();
}
=======end sample program========

I don't see anything wrong with this. Nevertheless, icc aborts the
compilation with the fatal error

testit.c(6): error: expected a ";"
{
^

It doesn't like the opening left-brace of "sub1".

Now, I've read this group before, and I know I'm going to get reamed
for such a simple question, but: what's wrong? And why does one
compiler pass it and the other doesn't?

This is in openSuse 10.3 on a 2.5GHz core 2 duo with 3GB RAM (though
none of that matters).

Thanks in advance,

--
Ron Bruck

Ronald Bruck wrote:
> Sigh. It's been awhile since I've programmed in C, but I'm SURE that
> you can have a function whose scope is purely within another function.
You simply can't do this in C.

> Yet here I have a program which compiles without a peep under gcc4.2.1
> (with -ansi -Wall, no less), AND runs correctly, but which icc
> (10.1.015) won't touch with a ten-foot-pole:
>
> =====begin sample program=====
> #include <stdio.h>
>
> int main()
> {
> int sub1()
> {
> printf("1");
> return(0);
> }
> int sub2()
> {
> printf("2\n");
> return(0);
> }
> /* start of main */
> sub1();
> sub2();
> }
> =======end sample program========
>
> I don't see anything wrong with this. Nevertheless, icc aborts the
> compilation with the fatal error
>
> testit.c(6): error: expected a ";"
> {
> ^
>
> It doesn't like the opening left-brace of "sub1".
>
> Now, I've read this group before, and I know I'm going to get reamed
> for such a simple question, but: what's wrong? And why does one
> compiler pass it and the other doesn't?
Which one takes it? Must be a non-conforming one then.

> This is in openSuse 10.3 on a 2.5GHz core 2 duo with 3GB RAM (though
> none of that matters).
>
> Thanks in advance,

Bye, Jojo

Joachim Schmitz wrote:
> Ronald Bruck wrote:
>> Sigh. It's been awhile since I've programmed in C, but I'm SURE that
>> you can have a function whose scope is purely within another
>> function. You simply can't do this in C.
>
>> Yet here I have a program which compiles without a peep under
>> gcc4.2.1 (with -ansi -Wall, no less), AND runs correctly, but which
>> icc (10.1.015) won't touch with a ten-foot-pole:
>>
>> =====begin sample program=====
>> #include <stdio.h>
>>
>> int main()
>> {
>> int sub1()
>> {
>> printf("1");
>> return(0);
>> }
>> int sub2()
>> {
>> printf("2\n");
>> return(0);
>> }
>> /* start of main */
>> sub1();
>> sub2();
>> }
>> =======end sample program========
>>
>> I don't see anything wrong with this. Nevertheless, icc aborts the
>> compilation with the fatal error
>>
>> testit.c(6): error: expected a ";"
>> {
>> ^
>>
>> It doesn't like the opening left-brace of "sub1".
>>
>> Now, I've read this group before, and I know I'm going to get reamed
>> for such a simple question, but: what's wrong? And why does one
>> compiler pass it and the other doesn't?
> Which one takes it? Must be a non-conforming one then.
Ah, I see, gcc. Add -pedantic to switch off that non-standard extension

>> This is in openSuse 10.3 on a 2.5GHz core 2 duo with 3GB RAM (though
>> none of that matters).
>>
>> Thanks in advance,

Bye, Jojo

Ronald Bruck <bruck@math.usc.edu> wrote:
> Sigh. It's been awhile since I've programmed in C, but I'm SURE that
> you can have a function whose scope is purely within another function.

Only as a compiler specific extension. I guess you're mixing that
up with the posibility to declare (but not define) a function
within another function.

> Yet here I have a program which compiles without a peep under gcc4.2.1
> (with -ansi -Wall, no less),

Add '-pedantic' to the mix and it will tell you

z6.c:6: warning: ISO C forbids nested functions
z6.c:11: warning: ISO C forbids nested functions

> AND runs correctly, but which icc
> (10.1.015) won't touch with a ten-foot-pole:

So icc does not support this extension (at least not per
default as gcc does).

> =====begin sample program=====
> #include <stdio.h>

> int main()
> {
> int sub1()
> {
> printf("1");
> return(0);
> }
> int sub2()
> {
> printf("2\n");
> return(0);
> }
> /* start of main */
> sub1();
> sub2();
> }
> =======end sample program========

> I don't see anything wrong with this. Nevertheless, icc aborts the
> compilation with the fatal error

> testit.c(6): error: expected a ";"
> {
> ^

> It doesn't like the opening left-brace of "sub1".

Also gcc starts complaining about that line if you make it
really standard compliant with '-pedantic'. All allowed at
this place is a ';' to end the declaration of the function.
But the '{' starts a function definition instead.

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de

Ronald Bruck wrote:
>
> Sigh. It's been awhile since I've programmed in C, but I'm SURE
> that you can have a function whose scope is purely within another
> function. Yet here I have a program which compiles without a peep
> under gcc4.2.1 (with -ansi -Wall, no less), AND runs correctly,
> but which icc (10.1.015) won't touch with a ten-foot-pole:
>
.... snip ...
>
> Now, I've read this group before, and I know I'm going to get
> reamed for such a simple question, but: what's wrong? And why
> does one compiler pass it and the other doesn't?

Because you were using a non-standard extension of gcc. Local
functions are forbidden in standard C. If you run gcc properly
(with gcc -W -Wall -ansi -pedantic) so that it restricts itself to
standard C, it will reject that program too.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

"Joachim Schmitz" <nospam.jojo@schmitz-digital.de> writes:

> Ronald Bruck wrote:
>> Sigh. It's been awhile since I've programmed in C, but I'm SURE that
>> you can have a function whose scope is purely within another function.
> You simply can't do this in C.

Nonsense. Of course you can do this in C. Non "standard" extensions are
still "C" I am afraid.

Richard wrote:
> "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> writes:
>
>> Ronald Bruck wrote:
>>> Sigh. It's been awhile since I've programmed in C, but I'm SURE that
>>> you can have a function whose scope is purely within another function.
>> You simply can't do this in C.
>
> Nonsense. Of course you can do this in C. Non "standard" extensions are
> still "C" I am afraid.

Nonsense. And if you're afraid, cower.

--
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> Richard wrote:
>> "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> writes:
>>
>>> Ronald Bruck wrote:
>>>> Sigh. It's been awhile since I've programmed in C, but I'm SURE that
>>>> you can have a function whose scope is purely within another function.
>>> You simply can't do this in C.
>>
>> Nonsense. Of course you can do this in C. Non "standard" extensions are
>> still "C" I am afraid.
>
> Nonsense. And if you're afraid, cower.

So people using nested functions are not writing C?

Don't be so ridiculous.

Oh, and tell IBM.

http://publib.boulder.ibm.com/infoce..._functions.htm

On Sat, 31 May 2008 12:49:01 -0400, CBFalconer wrote:
> Because you were using a non-standard extension of gcc. Local functions
> are forbidden in standard C. If you run gcc properly (with gcc -W -Wall
> -ansi -pedantic) so that it restricts itself to standard C, it will
> reject that program too.

That's just plain wrong. If you had actually bothered to try it, you would
have found that gcc with your recommended options accepts the original
code (as permitted).

$ gcc -W -Wall -ansi -pedantic testit.c -o testit
testit.c: In function ‘main’:
testit.c:5: warning: ISO C forbids nested functions
testit.c:10: warning: ISO C forbids nested functions
testit.c:18: warning: control reaches end of non-void function
$ ./testit
12

Implementations aren't required to reject code with syntax errors or
constraint violations. GCC with your recommended options doesn't. This is
intentional, conforming, and documented.

Richard wrote:
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>
>> Richard wrote:
>>> "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> writes:
>>>
>>>> Ronald Bruck wrote:
>>>>> Sigh. It's been awhile since I've programmed in C, but I'm SURE that
>>>>> you can have a function whose scope is purely within another function.
>>>> You simply can't do this in C.
>>> Nonsense. Of course you can do this in C. Non "standard" extensions are
>>> still "C" I am afraid.
>> Nonsense. And if you're afraid, cower.
>
> So people using nested functions are not writing C?

No, no more than those who write `GOTO 10' are writing C.

> Don't be so ridiculous.

Don't be daft.

> Oh, and tell IBM.
>
> http://publib.boulder.ibm.com/infoce..._functions.htm

Quoting from the above: "The language feature is an
extension to C89 and C99, implemented to facilitate porting
programs developed with GNU C."

--
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> Richard wrote:
>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>
>>> Richard wrote:
>>>> "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> writes:
>>>>
>>>>> Ronald Bruck wrote:
>>>>>> Sigh. It's been awhile since I've programmed in C, but I'm SURE that
>>>>>> you can have a function whose scope is purely within another function.
>>>>> You simply can't do this in C.
>>>> Nonsense. Of course you can do this in C. Non "standard" extensions are
>>>> still "C" I am afraid.
>>> Nonsense. And if you're afraid, cower.
>>
>> So people using nested functions are not writing C?
>
> No, no more than those who write `GOTO 10' are writing C.
>
>> Don't be so ridiculous.
>
> Don't be daft.
>
>> Oh, and tell IBM.
>>
>> http://publib.boulder.ibm.com/infoce..._functions.htm
>
> Quoting from the above: "The language feature is an
> extension to C89 and C99, implemented to facilitate porting
> programs developed with GNU C."

I realise from your posting history that you like to be picky and
obstructive, but I am afraid they ARE writing C. It might not be "ISO
compliant C" (or whatever) but it is still C.

So Gnu supports them. IBM compilers them. Hey! Ring them up and tell
them it is "not C". It is C. Their C. Live with it.

Richard wrote:
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>
>> Richard wrote:
>>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>>
>>>> Richard wrote:
>>>>> "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> writes:
>>>>>
>>>>>> Ronald Bruck wrote:
>>>>>>> Sigh. It's been awhile since I've programmed in C, but I'm SURE that
>>>>>>> you can have a function whose scope is purely within another function.
>>>>>> You simply can't do this in C.
>>>>> Nonsense. Of course you can do this in C. Non "standard" extensions are
>>>>> still "C" I am afraid.
>>>> Nonsense. And if you're afraid, cower.
>>> So people using nested functions are not writing C?
>> No, no more than those who write `GOTO 10' are writing C.
>>
>>> Don't be so ridiculous.
>> Don't be daft.
>>
>>> Oh, and tell IBM.
>>>
>>> http://publib.boulder.ibm.com/infoce..._functions.htm
>> Quoting from the above: "The language feature is an
>> extension to C89 and C99, implemented to facilitate porting
>> programs developed with GNU C."
>
> I realise from your posting history that you like to be picky and
> obstructive, but I am afraid they ARE writing C. It might not be "ISO
> compliant C" (or whatever) but it is still C.
>
> So Gnu supports them. IBM compilers them. Hey! Ring them up and tell
> them it is "not C". It is C. Their C. Live with it.

The programming language C is defined by an International
Standard. Implementations behave as that Standard requires;
when they don't, it's a bug.

Gadgets like nested functions are defined with varying
degrees of specificity and completeness, by the whims of the
implementors who choose to provide them. If implementations
differ incompatibly concerning the details of how such a
gadget behaves, each of the various providers will tell you
it's a feature.

The IBM quote you dug up explicitly describes the feature
as quote an extension to C89 and C99 endquote, not as part of
the C language. Re-read it -- and, in your words, live with it.

--
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> Richard wrote:
> > Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> >
> >> Richard wrote:
> >>> "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> writes:
> >>>
> >>>> Ronald Bruck wrote:
> >>>>> Sigh. It's been awhile since I've programmed in C, but I'm SURE that
> >>>>> you can have a function whose scope is purely within another function.
> >>>> You simply can't do this in C.
> >>> Nonsense. Of course you can do this in C. Non "standard" extensions are
> >>> still "C" I am afraid.
> >> Nonsense. And if you're afraid, cower.
> >
> > So people using nested functions are not writing C?

> No, no more than those who write `GOTO 10' are writing C.

> > Don't be so ridiculous.

> Don't be daft.

I don't think it will if you ask this "Richard" character
not to be. He is and obviously can't it. Just whistle a
few bars of the Queen's song "Trolls will be trolls" and just
disregard him otherwise;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de

Harald van D?k wrote:
> CBFalconer wrote:
>
>> Because you were using a non-standard extension of gcc. Local
>> functions are forbidden in standard C. If you run gcc properly
>> (with gcc -W -Wall -ansi -pedantic) so that it restricts itself
>> to standard C, it will reject that program too.
>
> That's just plain wrong. If you had actually bothered to try it,
> you would have found that gcc with your recommended options
> accepts the original code (as permitted).
>
> $ gcc -W -Wall -ansi -pedantic testit.c -o testit
> testit.c: In function ‘main’:
> testit.c:5: warning: ISO C forbids nested functions
> testit.c:10: warning: ISO C forbids nested functions
> testit.c:18: warning: control reaches end of non-void function

I'm amused you consider that an acceptable result. Please flag all
your code so we know to avoid it.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

CBFalconer <cbfalconer@yahoo.com> writes:
> Harald van D?k wrote:
>> CBFalconer wrote:
>>
>>> Because you were using a non-standard extension of gcc. Local
>>> functions are forbidden in standard C. If you run gcc properly
>>> (with gcc -W -Wall -ansi -pedantic) so that it restricts itself
>>> to standard C, it will reject that program too.
>>
>> That's just plain wrong. If you had actually bothered to try it,
>> you would have found that gcc with your recommended options
>> accepts the original code (as permitted).
>>
>> $ gcc -W -Wall -ansi -pedantic testit.c -o testit
>> testit.c: In function ‘main’:
>> testit.c:5: warning: ISO C forbids nested functions
>> testit.c:10: warning: ISO C forbids nested functions
>> testit.c:18: warning: control reaches end of non-void function
>
> I'm amused you consider that an acceptable result. Please flag all
> your code so we know to avoid it.

The point is that a conforming compiler is merely required to issue a
diagnostic; it's not required to reject the program, which is what you
asserted. By printing a warning, gcc fullfilled the requirements of
the standard.

Harald didn't say he considered it "an acceptable result", merely that
it doesn't violate the standard.

A conforming C implementation is not required to *reject* any program
that doesn't use "#error".

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Joachim Schmitz said:

<snip>

> Which [compiler] takes [nested functions]? Must be a non-conforming
> one then.

Conforming implementations are required to diagnose programs that contain
at least one syntax error or constraint violation (and nested functions
certainly qualify), but they are not required to reject them. Nested
functions are a perfectly legal extension.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
> Joachim Schmitz said:
>
> <snip>
>
>> Which [compiler] takes [nested functions]? Must be a non-conforming
>> one then.
>
> Conforming implementations are required to diagnose programs that contain
> at least one syntax error or constraint violation (and nested functions
> certainly qualify), but they are not required to reject them. Nested
> functions are a perfectly legal extension.
>

Yes, when gcc is concerned.

When lcc-win does something similar the polemic never ends.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia said:

> Richard Heathfield wrote:
>> Joachim Schmitz said:
>>
>> <snip>
>>
>>> Which [compiler] takes [nested functions]? Must be a non-conforming
>>> one then.
>>
>> Conforming implementations are required to diagnose programs that
>> contain at least one syntax error or constraint violation (and nested
>> functions certainly qualify), but they are not required to reject them.
>> Nested functions are a perfectly legal extension.
>
> Yes, when gcc is concerned.

Where *any* conforming implementation is concerned.

> When lcc-win does something similar the polemic never ends.

Any conforming implementation may offer extensions, provided that they
don't break strictly conforming programs and provided that any syntax
errors or constraint violations result in at least one diagnostic message.
If lcc-win conforms to ISO C, it may offer extensions. And if it doesn't,
it is not bound by the requirements of the Standard in any case, so it's
hard to see what you're complaining about. It's equally hard to see why
you're complaining about it *here*. I suggest you take up the matter in
comp.compilers.lcc, where discussion of the lcc compiler is topical.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999