12 ms·
C functions (and in fact the "functions" of most mainstream programming languages) are not computations, they are algorithms. An algorithm doesn't necessarily h
by simiones 2y ago
C functions (and in fact the "functions" of most mainstream programming languages) are not computations, they are algorithms. An algorithm doesn't necessarily have a result of any kind, at least not in the way that a (mathematical) function has. The result of the algorithm can be the state in which it leaves the World (e.g. an algorithm for cleaning a house doesn't have a return value, it changes the state of the house).
In fact the traditional programming name for what we mostly call functions today was "(sub)routine" - you call a subroutine, and when it finishes, it returns to where it originally started.
Consider also that at the assembly level (and below it), subroutines don't have return values, nor arguments. The program counter simply jumps to the beginning address of the subroutine, and the `return` instruction jumps back to the address right after that jump. The subroutine may read values from certain locations in memory, and possibly write some others back, but none of this is necessary or enforced in any way. C functions, and the corresponding keywords, are much closer to this conception of assembly subroutines than they are to the mathematical notions of functions or computations.
- MobiusHorizons 2y agoThe calling convention does say where to look for the return value. So in a sense the return value always exists, but would not be meaningful if the function has a void return type.
- simiones 2y agoThe calling convention is part of the abstraction, it's not part of the processor's logic. Different languages often have different calling conventions, on the same OS and processor family. Different OSs have different calling conventions for their system calls.