On 11/26/2019 7:41 AM, Michael Wojcik wrote: > The Appendix K functions (memcpy_s, etc) do NOT "remove buffer > overflow kind of issues completely", and anyone who thinks they do is > making a serious error. The Appendix K functions impose an additional > check. That's all they do. It is possible, and in some use cases quite > easy, for the developer to pass the wrong value for the destsz > parameter and invalidate that check. > > Some C experts have argued that the length-checking versions of the > library functions, either the C90 ones such as strncat or the Appendix > K ones, are essentially pointless anyway; that the caller needs to > handle truncation and so ought to know whether truncation (or > overflow) would occur before attempting the operation.
I was initially a fan of them when I first heard of them, but have since soured on them, as have others. They are very nearly useless for libraries, because their behavior is controlled on a process-global basis. The library cannot assume that the "bad" cases will result in aborts, because the application might have chosen to have them return errors instead. That means that the library has to check for and handle all of those "should be impossible" error cases. Here's a paper on the subject: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris