The c11 appendix K string functions
memcpy_s, memmove_s, strcat_s, strcpy_s, strerror_s, strerrorlen_s,
strncat_s, strnlen_s, strtok_s, strncpy_s
This adds significant portion of the functions from the appendix. So there are two points I have in mind about the stuff:
My position is that the addition is fine, esp. if libext1.a is used.
That sounds reasonable. A couple of random remarks from my side:
I do not have strong opinion there. Probably the argument pro inclusion into the base is the same as for libstdthreads, which was added solely (?) because it is in C standard, and which specification was criticized.
- Are you aware of the existence of WG14 document N1967, titled "Field Experience With Annex K — Bounds Checking Interfaces"? That document proposes that annex K is removed from the specification.
Please see the followup to r316213 on src-svn@, https://lists.freebsd.org/pipermail/svn-src-head/2017-March/099157.html , where I explicitly cited the mentioned document. Again, my position is that from the PoV of the system' implementors, if API is useful for some consumers, then there is no reason to obstruct them. Discussion about the merits and flaws of the API is up to the consumers. We are interested in attracting the application programmers, and the cost of having low-maintanance set of functions is negligible. E.g., we were subjected to addition of vastly more stinking APIs to libc, like non-functional shreds of clang block runtime, with almost nobody noticing.
Even if Appendix K is removed from C2x, it cannot be removed from C11. For instance, we keep POSIX interfaces removed from later SUSvN.
The arguements in n1967 come down to 'It's safer but... '
For applications that want safer and are will to accept the cost, app. K is a good option.
If it is a seperate lib in the base, that is fine with me.
I am moving this work to an external project.
It is currently being reviewed internally.
I will let you know when it happens, my guess is in a week or two.
All of original submission should be removed from the base as it will conflict.
Do not create a competing libext1.