One, the default implementation of the error handler is a crash at runtime to "detect" the buffer size difference. Or, a custom handler can be used.
Worst case, this handler is turned off, truncation is silent, and overflow occurs the next time the buffer is used. Best case, the handler detects a problem, requiring new code to find minimum buffer size (that should have been there anyway); at which point, it's perfectly safe to use...the standard memcpy()!!!
Two, Microsoft's compiler warning spam recommends replacing standard calls with its own. The warnings often make legitimate uses of memcpy() look wrong in some way.
I sure hope I'm missing something, but this seems like a big waste of time.
To me, this seems a little desperate. Aren't they just shifting the bugs to a later stage? I guess a spurious read is slightly better than a spurious write, but it all seems incredibly arbitrary.
One, the default implementation of the error handler is a crash at runtime to "detect" the buffer size difference. Or, a custom handler can be used.
Worst case, this handler is turned off, truncation is silent, and overflow occurs the next time the buffer is used. Best case, the handler detects a problem, requiring new code to find minimum buffer size (that should have been there anyway); at which point, it's perfectly safe to use...the standard memcpy()!!!
Two, Microsoft's compiler warning spam recommends replacing standard calls with its own. The warnings often make legitimate uses of memcpy() look wrong in some way.
I sure hope I'm missing something, but this seems like a big waste of time.