(In reply to comment #17)
> Actually, why not have both? I think this plan would fit everyone:
No, it does not. It certainly does not.
It is not only the problem of recompiling the existing code, it's also the problem of fixing it and re-qualifying it. This plan has a huge cost... and it's vain.
The contract C programmers have with C and the C library is clear: we accept a fair amount of inefficency, but we don't have to program in assembly nor care about the system's internals. How many people still use the C library when it comes to be important to gain an addition plus a comparison?
The problem we're facing just made this fact plain: there is no reason why memcpy should not be memmove.
(In reply to comment #17)
> Actually, why not have both? I think this plan would fit everyone:
No, it does not. It certainly does not.
It is not only the problem of recompiling the existing code, it's also the problem of fixing it and re-qualifying it. This plan has a huge cost... and it's vain.
The contract C programmers have with C and the C library is clear: we accept a fair amount of inefficency, but we don't have to program in assembly nor care about the system's internals. How many people still use the C library when it comes to be important to gain an addition plus a comparison?
The problem we're facing just made this fact plain: there is no reason why memcpy should not be memmove.