In actual usage, however ...
int foo(char *inbuff)
{
char buff[12];
char ams[] = "Ai'nt microsoft smrat?";
/* Specifying the source size twice makes us mostest secure */
memcpy_s(buff, sizeof(ams), ams, sizeof(ams));
or
/* This error logic you've seen before. */
if (memcpy_s(buff + 32, sizeof(buff), ams, sizeof(ams))) printf("Disk full");
finally;
/* Caller allocated inbuff based on available RAM; We *KNOW* it's big enough, but we don't know its exact size. This fix allows us to kill warnings.
NOTE: already tried memcpy_s(inbuff, sizeof(inbuff), ams, sizeof(ams)), it didn't work for some reason, probably another compiler bug */
memcpy_s(inbuff, 999999, ams, sizeof(ams));
}
Kevin is right - of course it will "work" in certain cases. In those cases it has probably been implemented thousands of times already (likely as a macro). But replacing the original memcpy() gives a misplaced and dangerous sense of security where none actually exists.
In order to understand the strcpy/strlcpy strcat/strlcat benefit, you first have to understand why and how it works, then you have to follow the rules. But buffers don't have rules, and slapping on another size parameter for security is like slapping a non-matching fake chrome exhaust pipe on your ricer to make it go faster and sound better. So, yeah, Linus and DrPepper probably will pick it up.