FAQ 1.12--auto keyword

[Bill Pursell]

The faq (question 1.12) states that the keyword "auto" is completely
useless.
However, it is necessary to forward declare a nested function (for
gcc...I'm not sure if this is gcc specific or a language issue.)
In other words:

int
main(void)
{
AUTO int foo(void);
return 0;

int foo (void)
{
return 0;
}
}

is valid only if AUTO is "auto" and not empty. Is this a language
issue, or is allowing the forward declaration a gcc extension?
If a language issue, should the FAQ be modified?

[Skarmander]

Bill Pursell wrote:

The faq (question 1.12) states that the keyword "auto" is completely
useless.
However, it is necessary to forward declare a nested function (for
gcc...I'm not sure if this is gcc specific or a language issue.)
It's gcc specific. Nested functions are not part of the language proper.
Standard C does not allow function declarations to nest.
In other words:

int
main(void)
{
AUTO int foo(void);
return 0;

int foo (void)
{
return 0;
}
}

is valid only if AUTO is "auto" and not empty. Is this a language
issue, or is allowing the forward declaration a gcc extension?
Nested functions as a whole are a gcc extension, let alone forward declaring
them.
If a language issue, should the FAQ be modified?

It's not, and a note in the FAQ would not be wise, IMO, as this gets too
specific.

S.

[Keith Thompson]

"Bill Pursell" <bi**********@g mail.com> writes:

The faq (question 1.12) states that the keyword "auto" is completely
useless.
However, it is necessary to forward declare a nested function (for
gcc...I'm not sure if this is gcc specific or a language issue.)
In other words:

int
main(void)
{
AUTO int foo(void);
return 0;

int foo (void)
{
return 0;
}
}

is valid only if AUTO is "auto" and not empty. Is this a language
issue, or is allowing the forward declaration a gcc extension?
If a language issue, should the FAQ be modified?

Standard C doesn't allow nested function definitions.

gcc could have told you this:

% gcc -c -ansi -pedantic -DAUTO=auto tmp.c
tmp.c: In function `main':
tmp.c:4: warning: invalid storage class for function `foo'
tmp.c:8: warning: ISO C forbids nested functions
tmp.c:10: warning: ISO C90 forbids mixed declarations and code

(Same thing with "-std=c99", except that the last warning doesn't
show up.)

--
Keith Thompson (The_Other_Keit h) 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.

[Skarmander]

Skarmander wrote:

Bill Pursell wrote:

The faq (question 1.12) states that the keyword "auto" is completely
useless.
However, it is necessary to forward declare a nested function (for
gcc...I'm not sure if this is gcc specific or a language issue.)

It's gcc specific. Nested functions are not part of the language proper.
Standard C does not allow function declarations to nest.

That should be "definition s". A function declaration is allowed within a
function, although this is generally not done.

S.

[Richard Bos]

"Bill Pursell" <bi**********@g mail.com> wrote:

The faq (question 1.12) states that the keyword "auto" is completely
useless.
However, it is necessary to forward declare a nested function (for
gcc...I'm not sure if this is gcc specific or a language issue.)

There is no such thing as a nested function in ISO C.

If gcc allows nested functions, that's its business. However, if it
requires "auto" to forwardly declare them, this is broken. They should
have chosen "static".

Richard

[Bill Pursell]

Richard Bos wrote:

"Bill Pursell" <bi**********@g mail.com> wrote:

The faq (question 1.12) states that the keyword "auto" is completely
useless.
However, it is necessary to forward declare a nested function (for
gcc...I'm not sure if this is gcc specific or a language issue.)

There is no such thing as a nested function in ISO C.

If gcc allows nested functions, that's its business. However, if it
requires "auto" to forwardly declare them, this is broken. They should
have chosen "static".

Actually, I'm thinking the entire nested function idea is broken. When
I first saw it, I thought it was a neat idea, but I quickly changed my
impression of it to "interestin g curiosity". I now consider it
completely pointless. But it does raise a question for me.

If I want to get the same behavior as a nested function (and as
far as I can tell, all it gives you is the ability to have 2 different
functions with the same name in the same linkage unit), I
could do this:

#include <stdio.h>

static int
func0(int x)
{
return x;
}

static int
func1(int x)
{
return x +1;
}

static int
foo0(int x)
{
static int(*const func)(int) = func0;
return func(x);
}

static int
foo1(int x)
{
static int(*const func)(int) = func1;
return func(x);
}

int
main(void)
{
printf("%d\n", foo0(0));
printf("%d\n", foo1(0));
}

So both foo0() and foo1() can use the name "func" to
reference different functions. Now, my question is:
is this as efficient as coding it so that foo{i} calls func{i}
directly? It seems like there may be any extra step involved.
Is there a way I could code it so that the two are certainly
identical? I'm declaring each as const within foo to
try to make that happen, but I suspect it doesn't really
help.

[Keith Thompson]

"Bill Pursell" <bi**********@g mail.com> writes:
[...]

Actually, I'm thinking the entire nested function idea is broken. When
I first saw it, I thought it was a neat idea, but I quickly changed my
impression of it to "interestin g curiosity". I now consider it
completely pointless. But it does raise a question for me.

If I want to get the same behavior as a nested function (and as
far as I can tell, all it gives you is the ability to have 2 different
functions with the same name in the same linkage unit), I
could do this:

[snip]

In languages that support them, nested functions have visibility to
declarations in their parent functions.

--
Keith Thompson (The_Other_Keit h) 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.

[Vladimir S. Oka]

Bill Pursell opined:

Richard Bos wrote:

"Bill Pursell" <bi**********@g mail.com> wrote:

> The faq (question 1.12) states that the keyword "auto" is
> completely useless. However, it is necessary to forward declare a
> nested function (for gcc...I'm not sure if this is gcc specific or
> a language issue.)

There is no such thing as a nested function in ISO C.

If gcc allows nested functions, that's its business. However, if it
requires "auto" to forwardly declare them, this is broken. They
should have chosen "static".

Actually, I'm thinking the entire nested function idea is broken.
When I first saw it, I thought it was a neat idea, but I quickly
changed my impression of it to "interestin g curiosity". I now
consider it completely pointless. But it does raise a question for
me.

If I want to get the same behavior as a nested function (and as
far as I can tell, all it gives you is the ability to have 2
different functions with the same name in the same linkage unit)

Well, it gives you the ability to have functions that are visible only
in their outer function and nowhere else. IMHO, that has it's uses
(does Pascal background start to show?). Whether this feature should
be introduced in C, or whether it is a "must have", is a completely
different issue (IMHO, answer to both is no).

--
The face of war has never changed. Surely it is more logical to heal
than to kill.
-- Surak of Vulcan, "The Savage Curtain", stardate 5906.5

<http://clc-wiki.net/wiki/Introduction_to _comp.lang.c>

[Michael Wojcik]

In article <44************ ***********@new s.xs4all.nl>, Skarmander <in*****@dontma ilme.com> writes:

Skarmander wrote:

It's gcc specific. Nested functions are not part of the language proper.
Standard C does not allow function declarations to nest.
That should be "definition s". A function declaration is allowed within a
function,

provided it does not use the "static" storage-class specifier,[1]
although this is generally not done.

Partly because the (mysterious) prohibition against the use of
"static" in this context means you can't declare a function at block
scope correctly if the function has internal linkage. Largely,
though, it's because it's not especially useful; it could potentially
be used to help a maintainer keep track of which functions are called
from which other functions, assuming a sufficiently verbose
implementation, but there are generally better ways of doing that.
1. C99 6.7.1 #5

--
Michael Wojcik mi************@ microfocus.com

Please enjoy the stereo action fully that will surprise you. -- Pizzicato Five

[Michael Wojcik]

In article <44************ ****@news.xs4al l.nl>, rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

"Bill Pursell" <bi**********@g mail.com> wrote:

The faq (question 1.12) states that the keyword "auto" is completely
useless.
However, it is necessary to forward declare a nested function (for
gcc...I'm not sure if this is gcc specific or a language issue.)

There is no such thing as a nested function in ISO C.

If gcc allows nested functions, that's its business. However, if it
requires "auto" to forwardly declare them, this is broken. They should
have chosen "static".

That's debatable. I think "auto" is more appropriate, since it
suggests the additional work necessary to provide the called nested
function with a link to the enclosing function's closure (using a
static chain or display or what have you) as part of its environment.
That, to me, is a more significant feature of nested functions than
their limited scope, which I imagine is what would justify yet
another application of "static".

Though to be honest I think reusing any of the existing keywords was
a bad idea; if they want to invent a new language, they should invent
a new language.

--
Michael Wojcik mi************@ microfocus.com

You brung in them two expert birdwatchers ... sayin' it was to keep us from
makin' dern fools of ourselfs ... whereas it's the inherent right of all to
make dern fools of theirselfs ... it ain't a right held by you official types
alone. -- Walt Kelly