The c11 appendix K string functions

[trix_juniper.net]

Summary

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

Test Plan

Add tests to provide at least 100% line coverage of new functions.
Run checkworld on amd64 and verify no failures.

[kib]

This adds significant portion of the functions from the appendix. So there are two points I have in mind about the stuff:

1. This probably should go into separate library, e.g. libext1.a, and memset_s should be moved from libc as well. If we keep existing symbol version, I think a straight face is enough to claim binary compatibility after the move.
2. Several people, at least ed@, said that they do not want to see other functions from the Appendix in a system library. I think we need some form of consensus there, before moving further.

My position is that the addition is fine, esp. if libext1.a is used.

[ed]

Hi Kostik,

In D10469#217186, @kib wrote:

This adds significant portion of the functions from the appendix. So there are two points I have in mind about the stuff:

1. This probably should go into separate library, e.g. libext1.a, and memset_s should be moved from libc as well. If we keep existing symbol version, I think a straight face is enough to claim binary compatibility after the move.
2. Several people, at least ed@, said that they do not want to see other functions from the Appendix in a system library. I think we need some form of consensus there, before moving further.

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:

1. If implemented as a separate library, maybe it would make more sense to maintain it outside the base system? What about making it a separate package and placing it in the ports tree? That way it can also be packaged easily by other operating systems.
2. 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.

[kib]

In D10469#217188, @ed wrote:

That sounds reasonable. A couple of random remarks from my side:

1. If implemented as a separate library, maybe it would make more sense to maintain it outside the base system? What about making it a separate package and placing it in the ports tree? That way it can also be packaged easily by other operating systems.

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.

1. 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.

[trix_juniper.net]

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.

[kib]

There is no further feedback. I propose to go forward with the separate library.

[trix_juniper.net]

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.

[trix_juniper.net]

The location of the external project is https://github.com/trixirt/libc11ext

[emaste]

There seems to be no change here or in https://github.com/trixirt/libc11ext in the last five years. @trix_juniper.net are you still planning to pursue this?

[stevek]

In D10469#794487, @emaste wrote:

There seems to be no change here or in https://github.com/trixirt/libc11ext in the last five years. @trix_juniper.net are you still planning to pursue this?

He left Juniper some few years ago, therefore I don't expect him to answer. I think we can just consider this abandoned for the sake of the review.