Electro-existentialism notwithstanding, different languages handle the problem of return-value bookkeeping in different ways, from functions being subroutines which don't return a value (any data modified by the subroutine must be somehow available by reference to the subroutine) to functions which exist solely for their return value, prohibiting side-effects (modification of out-of-scope data by in-scope references).

Okay, something in English, now, eh? Let's suppose we have a function that returns an integer. And let us also suppose that we are able to pass this function a reference (or, pointer) to a memory location we wish it to modify. And let us further suppose that the return value is always going to be zero. (I know, I know, it's bad programming practice. Slap me on the wrist, mama, I write functions like this all the time!) Now, of course we don't care what the return value is. So suppose we write it in The One True Language like so:

int    foo(char **string) {
    string   = do_something_with_string(*string);
    return 0;
    }

char *string = "Yobaby!";

foo(&string);

We can track the normal case within foo(), as the return value of do_something_with_string() is assigned to string. do_something() computes a value and returns it. That value (in this case, a pointer to a new version of the original string) is assigned to string. Then the variable string falls out of scope at return() and is destroyed, while the data created lives on in the location referenced by the **string argument.

Lost yet? Sorry . . . I'll try to be a bit more clear. The new version of the original string is still in existence, though it has not been returned by foo(). The return value of foo() does exist, and is written to a location in memory pending an assignment. However, since no assignment is performed, it falls out of scope and is placed in the bit bucket for reuse.

So, that, in far too many words, is where unassigned return values go. Limbo. Hades. The Great Bit Bucket in the Sky. The Beyond. The Happy Hunting Grounds.

Now, malloc()'ed memory for which you lose all pointers? Well, the compiler can only cut you so much slack . . . we call that a memory leak. (And yes, there have been languages, though thankfully none of any currency that I know of — though I may be mistaken — which require you as the programmer to explicitly dispense with return values, or they won't go out of scope until the end of the block in which the function was called. Now that's what I call annoying!

Note: So as not to be redundant, I purposely didn't make this writeup all-inclusive. See also function, return value, malloc, pointer, bit bucket if any of my assumptions are unfamiliar to you.