The code and the tests look good.
There's no man page.

Though the _s functions did make it into the C11 standard, there is a reason why they are in an appendix and not part of the core specification. They are controversial. I personally find them pretty much useless, and think of them as garbage that Microsoft managed to shove through WG14's throat. I've once read that Microsoft's implementation of these functions is also incompatible with what's described in the C11 appendix, but I have no sources to back that up right now.

In my opinion the only interesting part of the appendix is the definition of errno_t, which I think would improve the readability of code if used consistently. For example, if the man page of posix_fadvise() would use it, it would be more obvious that this function returns an error number, instead of depending on errno. Apart from that, I'm against adding any other features from the appendix. That said, if others disagree with me, then feel free to commit.

Yea, the _s functions are MS' NIH for other interfaces that had pre-dated their crazy by a lot.

The reason for adding this function is to improve security.
Memset is used to overwrite sensitive memory.
But the compiler can legally optimize away a memset.
The compiler can not optimize away memset_s.

A link with a deeper explanation
https://www.securecoding.cert.org/confluence/display/c/MSC06-C.+Beware+of+c
ompiler+optimizations

In D9903#204653, @trix_juniper.net wrote:

The reason for adding this function is to improve security.
Memset is used to overwrite sensitive memory.
But the compiler can legally optimize away a memset.
The compiler can not optimize away memset_s.

A link with a deeper explanation
https://www.securecoding.cert.org/confluence/display/c/MSC06-C.+Beware+of+c
ompiler+optimizations

In that case I find having memset_s() a better solution than adding some custom extension, like OpenBSD's explicit_bzero(). memset_s() is at least part of some standard. Still, I wonder about its effectiveness. Even these functions don't prevent a compiler from copying around/caching data into registers/memory, meaning parts of data may still be recovered.

That said, I don't want this to block you from adding this function to the C library. If other people think this function is useful, then feel free to commit.

I am working on the style problems.

On the use of STDC_LIB_EXT1
I would rather not have to implement the whole appendix K to just get
memset_s.
What are folks thoughts on removing STDC_LIB_EXT1 use altogether ?

In D9903#204716, @trix_juniper.net wrote:

I am working on the style problems.

On the use of STDC_LIB_EXT1
I would rather not have to implement the whole appendix K to just get
memset_s.
What are folks thoughts on removing STDC_LIB_EXT1 use altogether ?

I am fine with putting it into BSD_VISIBLE space. Still, do you plan to implement handlers and registration for handlers ? IMO this better be done, even if only for memset_s.

The handlers certainly would be useful if a full implementation of K was
done.
For a single function I don¹t think it would be very useful.
How much more useful would a handler have over a user just checking the
return ?

In D9903#204737, @trix_juniper.net wrote:

The handlers certainly would be useful if a full implementation of K was
done.
For a single function I don¹t think it would be very useful.
How much more useful would a handler have over a user just checking the
return ?

If user must perform pre-call validation, then the function interface is certainly not the interface described in the standard. This means that the function should not be called same as specified in the standard, to prevent both confusion and accidental invalid usage, where consumer expects the handlers to be called, while our implementation does something different.

If we don’t give them the function to register the handler there shouldn’t
be any expectation ;)

The handler interface is a part of the full K support and I believe
overkill if we only have a single K function.
I am in favor of full support.
Is that what everyone wants ?

A new idea..
What do people think about making the pointer access safer ?
It should be possible to look into the processes memory space and tell if
the memory accessed by the function is mostly valid.

Tom

In D9903#204943, @trix_juniper.net wrote:

If we don’t give them the function to register the handler there shouldn’t
be any expectation ;)

Exactly. That's also how macOS implements it, apparently.

In D9903#204944, @ed wrote:

In D9903#204943, @trix_juniper.net wrote:

If we don’t give them the function to register the handler there shouldn’t
be any expectation ;)

Exactly. That's also how macOS implements it, apparently.

IMO when implementing a part of the standard it is preferable to implement self-contained part. As I noted above, without handlers and registration interfaces, it is not a standard-defined memset_s. It is fine to implement only memset_s, but still everything that is referenced by the std text under this name, should be provided. IMO.

The remaining issues are minor, what do you plan about the committing stuff ? Do you have commit bit yourself or somebody with src commit bit who is willing to commit this ?

I do not have commit permissions.

I noted that set_constrain_handler_s() is not thread-safe. Please see D10161 for my take on it and several other style editings.

If you agree with the change, please provide me with the commit message. Specifically, I want to get from you the attributions (like 'Submitted by: mail / name', 'Sponsored by: company' as applicable).

Thank you.

My comment is in D10161

Attributes..
Submitted by: trix@juniper.net / Tom Rix
Sponsored by: Juniper Networks

Thanks for your help,
Tom