Private Function C
π£ ππ»ππ»ππ» ALL INFORMATION CLICK HERE ππ»ππ»ππ»
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
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
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
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
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
"Joachim Schmitz" 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.
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]:
Try the download section.
** Posted from http://www.teranews.com **
Richard wrote:
"Joachim Schmitz" 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
es*****@ieee-dot-org.invalid
Eric Sosman "Joachim Schmitz" >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 Richard wrote:
>>"Joachim Schmitz" Eric Sosman >Richard wrote:
"Joachim Schmitz" 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 Richard wrote:
>>Eric Sosman
>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
es*****@ieee-dot-org.invalid
Eric Sosman 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]:
Try the download section.
** Posted from http://www.teranews.com **
CBFalconer 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) ks***@mib.org
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Joachim Schmitz said:
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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield wrote:
Joachim Schmitz said:
>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:
>>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
Email: -http://www. +rjh@
Google users:
"Usenet is a strange place" - dmr 29 July 1999
Replies have been disabled for this discussion.
3 posts views Thread by Rajesh Garg | last post: by
1 post views Thread by Bob Rock | last post: by
1 post views Thread by Andrew Poulos | last post: by
8 posts views Thread by __PPS__ | last post: by
6 posts views Thread by harry | last post: by
10 posts views Thread by John Goche | last post: by
14 posts views Thread by v4vijayakumar | last post: by
13 posts views Thread by PragueExpat | last post: by
17 posts views Thread by Peng Yu | last post: by
6 posts views Thread by Vijay Meena | last post: by
reply views Thread by PrototypeChain | last post: by
reply views Thread by dreamtext | last post: by
reply views Thread by rvphilip | last post: by
reply views Thread by ioana budai | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by coderic | last post: by
2 posts views Thread by WiboData | last post: by
1 post views Thread by RenziavdWalt | last post: by
reply v
Sissy Fucked Bondage
Mike 18 Xvideos
Lesbian Story Movies
Art Lingerie Hd Video
Brazzers Sekis Vidyo
Private in C# | How to Implement Private in C# with Examples
C++: Calling private function in a class from the public ...
c++ - When/why to make function private in class? - Stack ...
Example of private member function in C++
Local functions - C# Programming Guide | Microsoft Docs
What are some techniques for implementing 'private ...
private keyword - C# Reference | Microsoft Docs
Difference between Public and Private in C++ with Example ...
Private Function C
