private functions

[Ronald Bruck]

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

[Joachim Schmitz]

Re: private functions

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]

Re: private functions

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

[Jens Thoms Toerring]

Re: private functions

Ronald Bruck <bruck@math.usc .eduwrote:

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

[Richard]

Re: private functions

"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrite s:

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.

[CBFalconer]

Re: private functions

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 **

[Eric Sosman]

Re: private functions

Richard wrote:

"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrite s:
>

>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

[Richard]

Re: private functions

Eric Sosman <esosman@ieee-dot-org.invalidwrit es:

Richard wrote:

>"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrite s:
>>

>>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/infocenter/lnxpcomp/v8v101/index.jsp?topic=/com.ibm.xlcpp8l.doc/language/ref/nested_functions.htm

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: private functions

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.

[Eric Sosman]

Re: private functions

Richard wrote:

Eric Sosman <esosman@ieee-dot-org.invalidwrit es:
>

>Richard wrote:

>>"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrite s:
>>>
>>>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

[Richard]

Re: private functions

Eric Sosman <esosman@ieee-dot-org.invalidwrit es:

Richard wrote:

>Eric Sosman <esosman@ieee-dot-org.invalidwrit es:
>>

>>Richard wrote:
>>>"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrite s:
>>>>
>>>>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.

[Eric Sosman]

Re: private functions

Richard wrote:

Eric Sosman <esosman@ieee-dot-org.invalidwrit es:
>

>Richard wrote:

>>Eric Sosman <esosman@ieee-dot-org.invalidwrit es:
>>>
>>>Richard wrote:
>>>>"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrite s:
>>>>>
>>>>>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

[Jens Thoms Toerring]

Re: private functions

Eric Sosman <esosman@ieee-dot-org.invalidwrot e:

Richard wrote:

Eric Sosman <esosman@ieee-dot-org.invalidwrit es:

Richard wrote:
>"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrite s:
>>
>>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 help if you ask this "Richard" character
not to be. He is and obviously can't help 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

[CBFalconer]

Re: private functions

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 **

[Keith Thompson]

Re: private functions

CBFalconer <cbfalconer@yah oo.comwrites:

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_Keit h) 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"