Good C style is that every function that accepts a callback should also accept an opaque context pointer it then passes through unchanged to the callback. Usually the caller will allocate a structure on the stack or the heap, stash some of its local variables there, then use them in the callback. A nested function does the structure back-and-forth for you in the stack-allocated case. In GCC’s original formulation it also passes the context pointer implicitly
size_t filter(bool (*predicate)(int), int *p, size_t n) {
for (size_t r = 0, w = 0; r < n; r++) {
if (predicate(p[r])) p[w++] = p[r];
}
return w;
}
size_t lowpass(int limit, int *p, size_t n) {
bool lower(int value) {
return value < limit; // use the parent's local variable
}
return filter(lower, p, n);
}
but that requires an executable stack and TFA is about avoiding that part.
Lambdas are just anonymous nested functions. But I like named nested functions more because they are more readable and would prefer them in most cases.
Ideally you have both as most languages have.
I always wondered why C++ only added lambdas, but observing WG21 for a while, I assume this is just a random walk in language design. (not that it is different in WG14)
The important feature of lambdas is that they are expressions, not that they lack a name. The advantage of function expressions is you can write the body of the function exactly at the place where it is used. With GCC nested functions you either have to write the body of the function before its first use or else write the declaration of the function twice.
This matters for long chains of continuation passing:
foo(arg1, arg2, [](){
// do some work
bar(arg3, arg4, [](){
// do some more work
baz(arg5, arg6, [](){
});
});
});
Compare to the following, where the control flow is all out of order:
void cb(void){
// Do some work
void cb2(void){
// do some more work
void cb3(void){
}
baz(arg5, arg6, cb3);
}
bar(arg3, arg4, cb2);
}
foo(arg1, arg2, cb);
But I usually prefer the later anyway, because the code usually is not as nested anyway and having a name is often helpful, and also because I find the nested code with lambdas also not too readable. Other languages have better syntax for chaining functions in this way, i.e. with lambdas I would like to write like this:
I can write numbers like three by just writing 3 in my code. When I want a named number I use a syntax like x = 3. Why should functions be any different? A language doesn't need different ways to name things for each type of thing. Integers, strings, functions etc: they can all use the same mechanism for naming.
I agree if your language is designed like this from the beginning as functional languages are, but in C you already have different syntax for functions. (edit: rephrased)
C++ bundles together a way to write functions inline in an expression (what I’d call “lambdas” in general) and a way to create closures with strictly nested lifetimes, but there’s no law of nature tying the two together. Even in C++ the essentially separate declaration “auto f = [&](... blah ...) { ... 50 lines of code ... };” is pretty common. (And of course GCC’s nested functions predate C++11 by twenty years.)
For a counterpoint, see David R. Hanson's "Is block structure necessary?" (1981) [0] — back in those days, "block structure" meant nested routines with nested scopes — which argues that having instead a proper module system, with explicit control over what's being exported from a module, not only gives a better modularity, decomposition, and encapsulation, but also simplifies both the language's implementation, and the run-time structures it needs (remember displays, and the hardware support for them e.g. x86's ENTER?).
Block structure is traditionally considered an a priori requirement for algorithmic program-
ming languages. Most new languages since Algol-60 have block structure. Reasons exist,
however, to omit the general form of block structure — nested procedure definitions in which
references to identifiers defined in outer procedures are permitted — from programming
languages, especially those intended for systems programming applications. This paper
reviews the concept of block structure and considers its advantages and disadvantages. It
concludes that, in many cases, a module facility is superior to block structure and should be
considered in lieu of block structure in future languages.
The traditional way of doing this in C is simply static functions. Every .c file has exactly one non-static function and all the other helper functions are static.
I use them all the time. It's one of the nicest and cleanest features of D. It's an elegant way of:
1. grouping together strongly related functions that are implicitly private to the enclosing function
2. obviating the need to create a struct in order to pass common context to multiple functions
For an example, here's a tree walking function that uses a nested function for the recursion:
private void unrollWalker(elem* e, uint defnum, Symbol* v, targ_llong increment, int unrolls) nothrow
{
int state = 0;
/***********************************
* Walk e in execution order, fixing it according to state.
* state == 0..unrolls-1: when eincrement is found, remove it, advance to next state
* state == 1..unrolls-1: replacing instances of v with v+(state*increment),
* state == unrolls-1: leave eincrement alone, advance to next state
* state == unrolls: done
*/
void walker(elem* e) @trusted
{
assert(e);
const op = e.Eoper;
if (ERTOL(e))
{
if (e.Edef != defnum)
{
walker(e.E2); // this function is @trusted because of this union access
walker(e.E1);
}
}
else if (OTbinary(op))
{
if (e.Edef != defnum)
{
walker(e.E1);
walker(e.E2);
}
}
else if (OTunary(op))
{
assert(e.Edef != defnum);
walker(e.E1);
}
else if (op == OPvar &&
state &&
e.Vsym == v)
{
// overwrite e with (v+increment)
elem* e1 = el_calloc();
el_copy(e1,e);
e.Eoper = OPadd;
e.E1 = e1;
e.E2 = el_long(e.Ety, increment * state);
}
if (OTdef(op) && e.Edef == defnum)
{
// found the increment elem; neuter all but the last one
if (state + 1 < unrolls)
{
el_free(e.E1);
el_free(e.E2);
e.Eoper = OPconst;
e.Vllong = 0;
}
++state;
}
}
walker(e);
assert(state == unrolls);
}
Only one argument needs to be passed to walker(), because the other context data is accessible from the enclosing function.
For the non-capturing case: mainly to improve readability by allowing utility functions to be defined close to where they are used and with short names.
For the capturing case: to access context that is not available through global variables or function arguments, i.e., the same reason why closures are useful in other languages.
Here's an example, where I have a list of points that I want to sort based on distance to a chosen target point. I can use qsort() which takes an arbitrary comparison function, but has no way to provide context to that function beyond the input arguments:
#include <stdio.h>
#include <stdlib.h>
int main() {
struct Point {
int x, y;
} points[3] = {
{ 3, 1 },
{ 2, 2 },
{ 5, 7 } };
struct Point target = { 4, 5 };
long dsq(const struct Point *p) {
long dx = p->x - target.x, dy = p->y - target.y;
return dx*dx + dy*dy;
}
int compare(const void *p, const void *q) {
long a = dsq(p), b = dsq(q);
return (a > b) - (a < b);
}
qsort(points, 3, sizeof(struct Point), compare);
for (int i = 0; i < 3; ++i) {
printf("%d,%d\n", points[i].x, points[i].y);
}
}
Note here that dsq() is a local function that accesses the `target` variable in the local function scope.
The usual workaround in standard C is to pass the necessary context as a function argument. That's why qsort_r() exists, which takes a context argument to be passed to compare(), but that's a non-standard GNU extension.
This practice of passing context pointers around is ubiquitous in C code, and it works, but it can get messy especially if you need access to multiple variables or variables from more than one nested scope. There is also a type safety issue: these context pointers are necessarily passed as void* which means they have to be cast back to the real type before use, which is where bugs can be introduced if the caller and receiver disagree on the actual type.
int main() {
struct Point {
int x, y;
} points[3] = {
{ 3, 1 },
{ 2, 2 },
{ 5, 7 }
};
struct Point target = { 4, 5 };
long dsq(const struct Point *p) {
long dx = p->x - target.x, dy = p->y - target.y;
return dx*dx + dy*dy;
}
typedef typeof(dsq) dsq_f;
int compare(const void *p, const void *q, void *data) {
wide(dsq_f) *dsq = data;
long a = CALL(*dsq, (p)), b = CALL(*dsq, (q));
return (a > b) - (a < b);
}
qsort_r(points, 3, sizeof(struct Point), compare, &CLOSURE(dsq_f, dsq));
for (int i = 0; i < 3; ++i)
printf("%d,%d\n", points[i].x, points[i].y);
}
There are slightly different ways how to define the helper macros, I am still experimenting a bit. Here you could avoid the typedef if defined differently. But ideally, there would be native language support that avoids these macros.
Fair. If you only have one object to access such as the target pointer, then it probably makes not much difference with void-pointer based APIs such as qsort_r (for new APIs it would add type safety). Where it removes more boilerplate code is when you have several such objects and would have to create an extra data structure to access them.
What about your older patch where -fno-trampolines meant a function pointer could either be a code pointer or a closure (descriptor) pointer, distinguished by a tag?
Nested functions have a different ABI from regular C functions, due to the invisible static chain register that needs to be set up. C has no way of indicating this different ABI, so GCC happily lets you cast a nested function to a C function pointer by creating a little tiny function that puts the right value in the static chain register before calling the nested function. This little tiny function is the trampoline.
Since the trampoline needs to live somewhere, GCC puts it on the stack, requiring the stack to be executable and consequently a whole lot of people hate the feature because it's a walking security nightmare.
Correct (although the nightmare part is a bit exaggerated since return-oriented programming showed that non-executable stack does not help a lot). GCC can also put the trampoline on the heap, but this also has downsides.
For me the main downside of trampolines is that the optimizer can not de-virtualize the trampoline again. This could be implemented, but avoiding the creation of the trampoline in the first place is much better.
C++ solves this problem by simply not allowing a nested function (lambda) to be converted to a function pointer, and thereby avoids this problem of trampolines and executable stack altogether. I think that’s a better design.
C++ has the same solution as I propose here: A wide function pointer type.
In C++ it is called std::function, but this comes with a bit of baggage. C++ 26 has std::function_ref which would be the exact equivalent to my wide pointer.
A C++ lambda that doesn't close over anything can be converted to a function pointer: https://eel.is/c++draft/expr.prim.lambda#closure-12 This feature does turn out to be useful if you need to pun a C++ interface into a function pointer for a C ABI function.
Could be a number of things depending on context. In this case it’s a short function that adjusts some things and jumps to the actual functions (a “thunk” is another term for this). Specifically, if in GCC you write
int f(int x) {
int g(int y) { ... use x and y ... }
...
h(&g);
...
}
then what the compiled code for f does is construct on the stack a short piece of machine code:
mov <well-known register>, <frame pointer>
jmp <start of g’s code>
and &g points to the start not of g’s code but of this snippet on the stack, which has the parent function’s frame pointer compiled into it as a literal constant. The snippet is called a trampoline.
Why would someone want to use a nested function, practically speaking?
Good C style is that every function that accepts a callback should also accept an opaque context pointer it then passes through unchanged to the callback. Usually the caller will allocate a structure on the stack or the heap, stash some of its local variables there, then use them in the callback. A nested function does the structure back-and-forth for you in the stack-allocated case. In GCC’s original formulation it also passes the context pointer implicitly
but that requires an executable stack and TFA is about avoiding that part.When you want to use lambdas, but your language doesn't have lambdas, so you reach for the nearest thing instead.
Lambdas are just anonymous nested functions. But I like named nested functions more because they are more readable and would prefer them in most cases. Ideally you have both as most languages have.
I always wondered why C++ only added lambdas, but observing WG21 for a while, I assume this is just a random walk in language design. (not that it is different in WG14)
> Lambdas are just anonymous nested functions.
The important feature of lambdas is that they are expressions, not that they lack a name. The advantage of function expressions is you can write the body of the function exactly at the place where it is used. With GCC nested functions you either have to write the body of the function before its first use or else write the declaration of the function twice.
This matters for long chains of continuation passing:
Compare to the following, where the control flow is all out of order:I agree with your point.
But I usually prefer the later anyway, because the code usually is not as nested anyway and having a name is often helpful, and also because I find the nested code with lambdas also not too readable. Other languages have better syntax for chaining functions in this way, i.e. with lambdas I would like to write like this:
(edit: or something, I think I got it a bit wrong, but you get the idea)But I agree, sometimes lambdas are better so it would be good to have both.
(There is the classical hack to define lambdas using statement expressions and nested functions.)
I can write numbers like three by just writing 3 in my code. When I want a named number I use a syntax like x = 3. Why should functions be any different? A language doesn't need different ways to name things for each type of thing. Integers, strings, functions etc: they can all use the same mechanism for naming.
I agree if your language is designed like this from the beginning as functional languages are, but in C you already have different syntax for functions. (edit: rephrased)
C++ bundles together a way to write functions inline in an expression (what I’d call “lambdas” in general) and a way to create closures with strictly nested lifetimes, but there’s no law of nature tying the two together. Even in C++ the essentially separate declaration “auto f = [&](... blah ...) { ... 50 lines of code ... };” is pretty common. (And of course GCC’s nested functions predate C++11 by twenty years.)
Say to strictly enforce modularity, e.g helper functions that can only be accessed within its function.
Pascal supports it (at least Turbo Pascal, no idea about ISO Pascal).
For a counterpoint, see David R. Hanson's "Is block structure necessary?" (1981) [0] — back in those days, "block structure" meant nested routines with nested scopes — which argues that having instead a proper module system, with explicit control over what's being exported from a module, not only gives a better modularity, decomposition, and encapsulation, but also simplifies both the language's implementation, and the run-time structures it needs (remember displays, and the hardware support for them e.g. x86's ENTER?).
[0] https://drh.github.io/documents/blockstructure.pdfThe traditional way of doing this in C is simply static functions. Every .c file has exactly one non-static function and all the other helper functions are static.
I use them all the time. It's one of the nicest and cleanest features of D. It's an elegant way of:
1. grouping together strongly related functions that are implicitly private to the enclosing function
2. obviating the need to create a struct in order to pass common context to multiple functions
For an example, here's a tree walking function that uses a nested function for the recursion:
Only one argument needs to be passed to walker(), because the other context data is accessible from the enclosing function.https://github.com/dlang/dmd/blob/master/compiler/src/dmd/ba...
RAII style cleanup e.g. no gotos
For the non-capturing case: mainly to improve readability by allowing utility functions to be defined close to where they are used and with short names.
For the capturing case: to access context that is not available through global variables or function arguments, i.e., the same reason why closures are useful in other languages.
Here's an example, where I have a list of points that I want to sort based on distance to a chosen target point. I can use qsort() which takes an arbitrary comparison function, but has no way to provide context to that function beyond the input arguments:
Note here that dsq() is a local function that accesses the `target` variable in the local function scope.The usual workaround in standard C is to pass the necessary context as a function argument. That's why qsort_r() exists, which takes a context argument to be passed to compare(), but that's a non-standard GNU extension.
This practice of passing context pointers around is ubiquitous in C code, and it works, but it can get messy especially if you need access to multiple variables or variables from more than one nested scope. There is also a type safety issue: these context pointers are necessarily passed as void* which means they have to be cast back to the real type before use, which is where bugs can be introduced if the caller and receiver disagree on the actual type.
This is a good example. Without trampolines, this could look like this (Godbolt: https://godbolt.org/z/nK5fqMxjs).
There are slightly different ways how to define the helper macros, I am still experimenting a bit. Here you could avoid the typedef if defined differently. But ideally, there would be native language support that avoids these macros.Well, if you're already using qsort_r, what's the point of using nested functions, if you can have a context pointer with the target?
And if you're not using qsort_r, but reaching for _Thread_local, the target can be _Thread_local instead of dsq.
Fair. If you only have one object to access such as the target pointer, then it probably makes not much difference with void-pointer based APIs such as qsort_r (for new APIs it would add type safety). Where it removes more boilerplate code is when you have several such objects and would have to create an extra data structure to access them.
Or without qsort_r, you could use a thread local variable:
https://godbolt.org/z/3e157c6b1Encapsulation
Just a little cleaner than placing it in the global or file namespaces.
So that you can name a section of code without polluting the namespace.
What about your older patch where -fno-trampolines meant a function pointer could either be a code pointer or a closure (descriptor) pointer, distinguished by a tag?
My old patch from 2018? This was not accepted to GCC because it relied on function pointers being aligned and there were concerns with this.
But I prefer this approach anyhow, as it does not impose any run-time cost for checking the tag, and is easier to optimize.
What's a "trampoline"?
In this context:
Nested functions have a different ABI from regular C functions, due to the invisible static chain register that needs to be set up. C has no way of indicating this different ABI, so GCC happily lets you cast a nested function to a C function pointer by creating a little tiny function that puts the right value in the static chain register before calling the nested function. This little tiny function is the trampoline.
Since the trampoline needs to live somewhere, GCC puts it on the stack, requiring the stack to be executable and consequently a whole lot of people hate the feature because it's a walking security nightmare.
Correct (although the nightmare part is a bit exaggerated since return-oriented programming showed that non-executable stack does not help a lot). GCC can also put the trampoline on the heap, but this also has downsides.
For me the main downside of trampolines is that the optimizer can not de-virtualize the trampoline again. This could be implemented, but avoiding the creation of the trampoline in the first place is much better.
C++ solves this problem by simply not allowing a nested function (lambda) to be converted to a function pointer, and thereby avoids this problem of trampolines and executable stack altogether. I think that’s a better design.
C++ has the same solution as I propose here: A wide function pointer type.
In C++ it is called std::function, but this comes with a bit of baggage. C++ 26 has std::function_ref which would be the exact equivalent to my wide pointer.
https://godbolt.org/z/GaP9jb5rE
A C++ lambda that doesn't close over anything can be converted to a function pointer: https://eel.is/c++draft/expr.prim.lambda#closure-12 This feature does turn out to be useful if you need to pun a C++ interface into a function pointer for a C ABI function.
Could be a number of things depending on context. In this case it’s a short function that adjusts some things and jumps to the actual functions (a “thunk” is another term for this). Specifically, if in GCC you write
then what the compiled code for f does is construct on the stack a short piece of machine code: and &g points to the start not of g’s code but of this snippet on the stack, which has the parent function’s frame pointer compiled into it as a literal constant. The snippet is called a trampoline.It's where you jump and then get immediately bounced back. Basically GOTOs with params
If you have proper tail call optimisation, then tail calls are GOTOs with params.
Trampolines allow you to simulate that, even when your compiler / language doesn't handle tail calls properly.
https://en.wikipedia.org/wiki/Trampoline_(computing)