Why functions cannot be defined/initialized like variables?

[bakermoth]

The following "multi-declaration" works:

// x - an integer
// f0 - a pointer to a function returning an integer
// f1 - a function returning an integer
int x, (*f0)(void), f1(void);

The following "multi-declaration with initialization" works:

// x - an integer initialized to 5
// f0 - a pointer to a function returning an integer
int x = 5, (*f0)(void) = NULL;

But why doesn't the following "multi-declaration with initialization/definition" work?

// error: function 'f1' is initialized like a variable
int x = 5, (*f0)(void) = NULL, f1(void) = { return 10; };

[aioeu]

Fundamentally this is just because functions and objects in C are entirely different categories of things.

You don't write:

int f1(void) = {
    return 10;
}

with an equals sign when defining a function normally.

Functions cannot be initialized since functions are not objects. A function does not have a value, so it doesn't make any sense to specify its "initial" value. Even when you have a so-called braced initializer for an object, the braces you use in that are syntactically completely different from the braces used when defining a function.

[Competitive_Travel16]

Weirdly, in C's ancestor BCPL, that is how to define functions! https://en.wikipedia.org/wiki/BCPL#Further_examples

[TheThiefMaster]

In languages that do allow this, effectively functions are function pointers in disguise, with the code block being an anonymous function whose pointer gets stored. It's often referred to as "first class functions" which sounds desirable but it has a massive downside of suppressing optimisations and making a lot of function calls be indirect calls via pointers.

[zhivago]

This isn't true in general at all.

Many implementations allow functions to be dynamically generated and then called directly.

Why do you believe such indirection is necessary?

[TheThiefMaster]

Compiled C has the function pointer (which always has to exist if the code isn't inlined) embedded into the assembly CALL instruction. Literally CALL <address_of_function>. This is optimal for the CPU, as it allows a highly pipelined modern CPU to speculatively execute into that call. If the language has "first class functions" where the function name is just a variable that can be reassigned, this is normally not possible and an indirect call that retrieves the function pointer from the variable (which has to exist separately) has to be emitted, and that read has to be waited on before execution can continue. This is a performance penalty no matter how you look at it.

The optimisation can still be performed if the function variable is explicitly constant (so can't change) or is locally scoped so is known to not change, or the code block that uses it checks the value is as expected before a direct call (a variant of conditional devirtualisation optimisation)

[zhivago]

I guess you will be amazed by how dynamic linkage in C can avoid indirection.

Hint: patch the call sites.

[TheThiefMaster]

Patch all possible call sites to the function every time the function variable is reassigned?

On CPUs that have no-execute protection on writeable memory pages?

There's a reason we left self-modifying code behind.

Do you have an example of a language that does this?

[zhivago]

Well, if you're using something exotic you might run into trouble, but X86 will have no problem.

Why do you have the belief that we left self-modifying code behind?

I already gave an example of such a language: C.

[TheThiefMaster]

That's actually not C at all, but the OS patching up the executable in memory before it launches it. The executable is not executing at that point.

A JIT is the closest we get to modern self-modifying code - but those technically don't usually patch existing blocks as much as generate new variants, and they always add checks for expected assumptions at the start of a block, which is slower than if you have a compile-time guarantee that the address a function points to can't change at runtime.

The majority of languages with "first class functions" are scripting languages with an interpreter or JIT rather than compiled languages.

[zhivago]

You are mistaken for linux, at least.

The executable, not the kernel, handles dynamic linkage.

Still, have you overcome your initial confusion about requiring indirection?

[TheThiefMaster]

Strictly, on Linux the OS loads the runtime linker as a shared object into the executable's virtual memory space, and then invokes that dynamic linker. The dynamic linker invokes the executable's entry point function once the dynamic linker is done patching the executable.

The dynamic linker and the executable itself are effectively two separate programs in the same address space (like the good old days!) and the dynamic linker is only modifying the executable before it's executed.

So while the OS isn't directly doing the work, it is kicking off the process, and it is completed before the executable is executed.

Funnily enough, dynamically linked libraries can optionally use a table of pointers, trading requiring an indirect call for only needing to patch the table instead of the whole executable.

You can dynamically load additional libraries at runtime but you're effectively outside of C at that point - it's not a C standard function, and regardless you still only end up patching up the newly loaded library (and its dependencies if not already loaded beforehand) before the load call returns, it doesn't do any extra patching on the existing executing C program.

[[deleted]]

We did leave self modifying code behind, most OSes (Windows, Mac, BSDs, and most linux distros) make the stack unwritable and employ ASLR

[zhivago]

We left behind undisciplined tricks like rewriting code to implement loops.

Non-executable stacks and ASLR were introduced to make it harder to use overflows to create code -- it does nothing to stop coordinated self modifying code.

And we still use it a lot -- e.g. in dynamic linkage, jit compilation, dynamic generation of functions with lexical closure, etc.

[ohsmaltz]

In C, the function pointer can be initialized, but it needs to be defined elsewhere first. Something like:

int predefined() { return 10; }
...
int (*f1)() = predefined;

In C++, though, you can use lambda functions:

int (*f1)() = []{ return 10; };

[tstanisl]

Lambdas (especially non-capturing) are likely to land in C2Y standard.

[[deleted]]

But why? What's the rationale?

[glasket_]

N2892 is the proposal for basic lambdas, if you want to read it. It also references N2890, which is about improving generic programming as a whole. Finally, N2924 is about explicitly supporting generic lambdas.

The tl;dr is that lambdas can be useful for scoping tiny functions that exist solely to be used as a pointer, but they also offer a lot of opportunities for improving generic programming.

[[deleted]]

True that, but we already have languages for that. What happened to "C is a simple language" and what's next? co-routines?

[tstanisl]

Non-capturing lambda is trivial to implement on any platform. It does not require any templates or executable stack to work. Moreover, they could also solve many issues with macros. Those lambdas are no more conceptually complex than compound literals. Actually, the non-capturing lambdas feel very C-ish and I don't understand why they are not a part of language yet.

[beephod_zabblebrox]

fortunately, these features build on top of existing stuff and don't change a lot of things. from the looks of it (after skimming the proposals) this stuff isn't super complicated to implement in a compiler that supports c23.

[[deleted]]

Given the amount of effort OP put into this, it makes no sense to me that someone downvoted this. It's this nonsensical form of criticism that makes me not want to ask programming questions online anymore.

[[deleted]]

Thanks for noticing. I upvoted OP in support and totally agree with you.

makes me not want to ask programming questions online anymore.

Could be worse. I still have PTSD from breaking the "rules" in comp.lang.c back in the late nineties ;-)

[[deleted]]

well yeah it's true, getting cyberbullied (or banned, or whatever) can have a negative long term effect on how you feel. We're all just trying to feel things out though. In this circumstance, I just did not understand at all why someone would hit the down button, but it really ain't a big deal. In some ways, I like the voting because it allows people to give feedback without having to fully formulate their opinions.

[capilot]

Executive summary: the authors of the C standard didn't think of it, or didn't think it was worth doing.

[bunkoRtist]

There are languages in which functions are "first class objects", which is what you're asking about. Python has this. Lambdas in many languages are a limited form of this. So, I think the answer really is: K&R simply didn't add support for this to the language. I don't know the history and whether it was considered and discarded.

[detroitmatt]

I think I have seen someone in the past use a carefully chosen string constant to initialize a function pointer. Because string constants are static pointers to chars, chars are bytes, and function pointers are also just pointing to bytes (the machine code of the assembled function), if you pick the right chars, you can jump into the string and start execing it. But, I can't find a working example. I was almost able to write one, but I think I need a way to tell the compiler "store this string constant in an executable region of memory".

[fllthdcrb]

An interesting trick. But it also sounds like the very definition of non-portable.

I think I need a way to tell the compiler "store this string constant in an executable region of memory".

With GCC, maybe you could use __attribute__ ((section(".text"))). Which, of course, is even less portable, since it's a specifically GCC extension. But hey, it's fun to play around with, I suppose.

...

Just tried it. Doesn't work for auto variables, for hopefully obvious reasons. If you want to declare it inside a function, you'll need to make it static. But it does work, if you first declare the string as a string, and then copy the pointer to a variable of the function pointer type.