Mind you, it probably won't perform well or do everything, but you can imagine it'd be easier than implementing an entire VM.
Unless it's video games.
People will write mountains of software to play an old video game.
Bit Rot is usually defined as all the ways that software can appear to stop serving it's function despite remaining the same, in the sense of being the same bits (or bytecode or interpreted code) run by the same computer.
"the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides."
See: https://en.wikipedia.org/wiki/Software_rot
Edit: Not being able to recreate or modify a given piece of software would an example of the bit of your tools/environment and this is one (but the only) source of bitrot in a piece of code.
0: http://www.russmiles.com/essais/dont-think-legacy-software-t...
In a nutshell, we can only safely use it if we somehow know that the source string fits into the destination buffer. Those situations are few: basically, they involve fixed-length string literals being moved into buffers that are "obviously" larger. E.g. some widget_t object has a char name[256] field, and we initialize it by default with strcpy(new_widget->name, "<unnamed widget>"), or some bullshit like that. The literal is way shorter than 256 and nobody in their right mind will ever make it that long, or shorten [256] in widget_t so that this literal doesn't fit.
In situations when we don't know the length of the source string, there are two cases: it is going into some buffer that is already allocated, or else we will be allocating one. In either situation, we must measure the length of the source string, to test whether it fits or to determine how much to allocate for it.
In the case when the string doesn't fit into the target buffer, we cannot use strcpy, obviously, since it copies the entire string. We use some truncating-copying function, or we handle the situation in some other way (diagnose the problem and abort or whatever).
In the case when we allocate, because we have calculated the length, we still should not use strcpy to finally copy the string. We should use memcpy, because memcpy doesn't wastefully examine every byte to see whether it is null.
So the opportunities for a correct, non-wasteful use of strcpy are few.
strncpy was not needed even in C90, because of sprintf, which is less clumsy to use, doing everything in one step:
char array[64];
sprintf(array, "%.63s", some_string);
sprintf(array, "%.*s", (int) sizeof array - 1, some_string);http://stackoverflow.com/questions/1694036/why-is-the-gets-f...
However, gets could have been "rescued" in C by requiring every implementation to publish a constant, say in <limits.h>, which indicates a maximum of how many bytes (including null terminator) the gets function will place into the target buffer, and ensuring that gets observes this constant.
Indeed, evidently, there was talk of this, and supposedly Doug Gwyn proposed that simply BUFSIZ be re-used for this purpose.
With such a constant in place, programs using gets could be wrenched out of the jaws of undefined behavior by sizing the input array according to that constant, ensuring that there cannot be overflow.
Rather than introducing this requirement, in the end the function was simply removed from the language.
One can use virtualization to help future-proof apps. IBM's System/38 (later AS/400, iSeries, and IBM i) did this for decades. However, to be fully future-proof (esp for vendor level), the virtualization SW/HW solution itself needs to be immune to the problem. That means legally, easily-cloned HW with same for software and virtualization layer. Closest thing maybe NOVA microhypervisor on Loongson-style OSS CPU with x86 emulation if it's x86 apps. RISC-V w/ virtualization support otherwise.
Guess what future-proof virtualization all the mainstream approaches aren't using, though? ;)
On the other hand this is a valid concern for containers.
Preserving order requires constant energy investment.
Just an analogy, but I find it useful.