Hacker News new | ask | show | jobs
by brigade 1862 days ago
Well for one, the language says a copy is made at the time of the function call, and it's perfectly valid to modify the original before the copy is finished being used. So pretty much any potentially aliasing write or function call in the callee would force a copy, and as he notes C's aliasing rules are lax enough that that's most of them.

Then if you care about the possibility of signal handlers modifying the original... you pretty much have to make a copy every time anyway.

1 comments

Plus any potential concurrency synchro point existing would force a copy, plus using any unknown function, etc.

Using rust and propagating the single writer xor multiple readers requirement in an ABI, this might be interesting. But with C/C++, I'm afraid copies would be forced "all" the time.

There's still a lot of functions which don't call unknown functions before accessing an argument passed by value, don't take the argument's address, etc. There are many simple functions such as this one:

    void print_foo(FILE *outf, struct foo foo) {
        fprintf(outf, "foo '%s': %i, %i\n", foo.name, foo.x, foo.y);
    }
That one would gain a speed-up and code-bloat reduction from the proposed ABI, and there are many like it.

But even if every single function had to fall back to making a copy, the argument is that there's still a significant code bloat saving by putting the copy in the callee rather than in the caller. After all, the instructions necessary to make a copy takes some space, and with the proposed ABI, those instructions are put in the called function, rather than in every function call. Most functions are called more than once, and all functions are called at least once (hopefully), so anything which can be changed from O(number of function calls) to O(number of functions) is an improvement.