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?

[Ben Pfaff]

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

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:

I once wrote some very nonportable, system- and compiler-specific
code that used GCC's nested function extension. The code is
below. Of course, I haven't included all of the necessary
declarations, etc. Your approach wouldn't allow me to do the
same thing so easily; I would have to pass a lot of arguments
back and forth to plot(), or encapsulate them in a structure, or
duplicate code.

/* Nonportable code that uses extensions. */
void
bogl_vga16_text (int xx, int yy, const char *s, int n, int fg, int bg,
struct bogl_font *font)
{
/* Font height, or possibly less due to clipping. */
int h;
int x, y;
unsigned long bits[font->height];

void plot (void)
{
volatile unsigned char *dst = frame + xx / 8 + yy * bogl_line_len;
int y, i;

for (y = 0; y < h; y++)
{
unsigned long b = bits[y];

for (i = ul_size - 1; i >= 0; i--)
{
set_mask (b);
rmw (dst + i);
b >>= 8;
}

dst += bogl_line_len;
}
}

assert (xx >= 0 && xx < bogl_xres);
assert (yy >= 0 && yy < bogl_yres);

h = font->height;
if (yy + h > bogl_yres)
h = bogl_yres - yy;

if (bg != -1)
{
int x2 = xx + bogl_metrics (s, n, font);
if (x2 >= bogl_xres)
x2 = bogl_xres - 1;

bogl_vga16_clea r (xx, yy, x2, yy + h, bg);
}

bogl_drawing = 1;

for (y = 0; y < h; y++)
bits[y] = 0;

set_color (fg);
select_mask ();

x = xx % ul_bits;
xx = xx / ul_bits * ul_bits;

for (; n--; s++)
{
const unsigned char ch = (unsigned char) *s;
const unsigned long *character = &font->content[font->offset[ch]];
const int width = font->width[ch];

for (y = 0; y < h; y++)
bits[y] |= character[y] >> x;
x += width;

if (x >= (int) ul_bits)
{
plot ();

x -= ul_bits;
for (y = 0; y < h; y++)
bits[y] = character[y] << (width - x);

xx += ul_bits;
if (xx >= bogl_xres)
goto done;
}
}
plot ();

done:
bogl_drawing = 0;
}
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[CBFalconer]

Bill Pursell wrote:

.... snip ...
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 you have ever used Pascal and similar languages you will soon
see the value of it. It allows careful control of scope, for
functions, variables and other things (eg. CONST in Pascal).
Unfortunately the gcc implementation effectively passes an extra
hidden parameter, and simply does not port. It is not necessary,
since you can achieve almost identical control to one nesting level
with multiple source files and some discipline.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell. org/google/>
Also see <http://www.safalra.com/special/googlegroupsrep ly/>

[Richard Bos]

mw*****@newsguy .com (Michael Wojcik) wrote:

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.

True; but for logistical reasons, gcc should not have used a keyword
that was existant but previously useless. It leads to confusion. Better
to invent a new one.
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".
Yes, but re-using "static" for purposes only tangentially related to
those it had before is Traditional.
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.

I agree. But that would not be as kewl as claiming you've written a C
compiler.

Richard

[Michael Wojcik]

In article <44************ ***@yahoo.com>, CBFalconer <cb********@yah oo.com> writes:

Bill Pursell wrote:

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.

If you have ever used Pascal and similar languages you will soon
see the value of it. It allows careful control of scope, for
functions, variables and other things (eg. CONST in Pascal).

Scope is not the only, nor to my mind the more interesting,
consequence of nesting functions.

Nested functions (in any proper implementation) capture their
ancestors' closures. That has potentially complex and interesting
consequences for program design.

Consider a recursive visitor-pattern function, for example - let's
say a function that iterates depth-first over a binary tree and calls
a delegate function at each node.

At the top level we have something like:

void Visit(struct tree *tree, void (*visitor)(stru ct tree *))
{
if (tree)
{
visitor(tree);
Visit(tree->left, visitor);
Visit(tree->right, visitor);
}
}

But if we have nested functions, we can push the recursion down a
level and hoist the visitor-function parameter out of it:

void Visit(struct tree *tree, void (*visitor)(stru ct tree *))
{
void Visit_r(struct tree *tree)
{
if (tree)
{
visitor(tree);
Visit(tree->left);
Visit(tree->right);
}
}

Visit_r(tree);
}

That saves us a parameter per recursive call, because Visit_r's
environment includes the current values of Visit's parameters and
local variables.

Now, in the actual implementation, there will likely be a hidden
parameter (as Chuck mentioned) for the static chain, unless the
implementation uses a display or some more esoteric mechanism. But
the nested-function representation is still clearer, as it only
explicitly passes the changing parameter, and if there are multiple
parameters that can be eliminated this way, there's a net savings.

However, C doesn't have nested functions, and adding them is a major
change to the language. There are plenty of programming languages
that *do* have nested functions, so people who want them have that
option. When I want a language with lots of expressive- ness, I use
OCaml or something like that. When I want to work in a tightly-
specified language with minimal black-box magic, I use C.

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

Proverbs for Paranoids, 1: You may never get to touch the Master,
but you can tickle his creatures. -- Thomas Pynchon

[Michael Wojcik]

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

mw*****@newsguy .com (Michael Wojcik) wrote:

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".

Yes, but re-using "static" for purposes only tangentially related to
those it had before is Traditional.

True - Seebs' Principle probably applies to extensions as well as
revisions of the standard. (And there's also Dennis' story of
prenatal new-keyword trauma...)

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.

I agree. But that would not be as kewl as claiming you've written a C
compiler.

I suppose not. There does seem to be (or at least have been) a fair
bit of "133t ski11z" sentiment among the GCC contributors. Could it
be that Stallman encouraged that?

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

As always, great patience and a clean work area are required for fulfillment
of this diversion, and it should not be attempted if either are compromised.
-- Chris Ware

[Mark McIntyre]

On Mon, 10 Apr 2006 20:21:12 -0400, in comp.lang.c , CBFalconer
<cb********@yah oo.com> wrote:

Bill Pursell wrote:

... snip ...

Actually, I'm thinking the entire nested function idea is broken.

If you have ever used Pascal and similar languages you will soon
see the value of it.

I've used Pascal, and indeed C++ which allows a similar idea, and
frankly, I can count on the fingers of one foot the number of times
I've needed an entire function to be private to another function. YMMV
of course.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan