[rurban]

Both glibc arguments are bogus.

First, to simply replace strcpy with strcpy_s is not possible on purpose. He cites that as disadvantage, but the advantage is that the user has to check for the error value and do something. Before the code ignored any errors and was happy with either UB, SEGV's or silent overwrites. Now some action has to be performed in the error case. The _s functions are not to be used as nested expressions.

The 2nd argument, that error callbacks are insecure, is also bogus. The current practice of env callbacks and overrides are much more insecure and slower. Look at the myriad of nonsense glibc put into their dynamic linker or malloc. LD_ this and MALLOC_ that. Same as a hacker can redirect the cb function to his, he can overwrite the process env block to set some evil LD_LIBRARY_PATH and load the evil .so. There are about 20 of those, safeclib has two.

safeclib is also not slower on good compilers. On recent clang it's even faster than glibc. glibc likes to break the optimization boundaries with asm, safec uses macros for zero-cost compile time checks, and proper code which can be easily inlined and tree optimized. That's why it can be safer and faster than glibc.

glibc does not support strings, only raw memory buffers, length or zero delimited. Strings are unicode nowadays. glibc does not care about strings and about its security implications. safec does.