Page MenuHomeFreeBSD

The c11 appendix K string functions
Needs ReviewPublic

Authored by trix_juniper.net on Apr 23 2017, 8:02 PM.

Details

Reviewers
kib
emaste
stevek
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.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

kib edited edge metadata.Apr 24 2017, 7:44 AM

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 edited edge metadata.Apr 24 2017, 8:04 AM

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 added a comment.Apr 24 2017, 8:41 AM
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.

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 added a comment.May 6 2017, 12:07 PM

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

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.

ed removed a reviewer: ed.Sep 6 2017, 12:05 PM