This could only be true if the returned value is placed on the stack (where the size of the reserved space is determined by the expected type), but usually a register suffices, and then it does not matter as much.
Consider a hypothetical flavour of the Deathstation 9000 architecture in which the ABI uses call-by-reference for return values, and for void functions there is no return value argument. If you get the declaration wrong, the arguments will be placed in the wrong registers.
These kinds of problems might not happen with common ABIs, but if you try to write C on the assumption that it will be compiled in a reasonable way based on your knowledge of how the plaform works, then modern compilers will punish you for your presumption.
> if you try to write C on the assumption that it will be compiled in a reasonable way based on your knowledge of how the plaform works, then modern compilers will punish you for your presumption.
Which is really a bug that everyone has decided to look the other way around because it wins compiler benchmarks despite coming against what C originally was meant for.
Specifically (from the C89 rationale[0], that i'm certain most people who think those benchmarks are good haven't read):
> C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the Committee did not want to force programmers into writing portably, to preclude the use of C as a ``high-level assembler'': the ability to write machine-specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program (§1.7).
Also in the same rationale it mentions how "the spirit of C" is to do operations in the way the machine would do it instead of forcing some abstract rule - yet that exactly is what happens later when everyone goes all language lawyer about C's abstract machine and how you should not rely on what you think the target machine would do.
