Probably means the extra-secure variant, more secure than the regular non-optimized-away memset that really clears the memory, but without the flush.
There is no need for a broken memset that fails to set some of the bytes, so that a fixed one under a different name has to be used in its place.
If you're using memset such that it's okay for memset not to set some of the bytes, and you'd like them not to be set if that makes things faster, then you shouldn't be using memset. You're using a hammer to drive a screw: wrong tool.
C has perfectly good initialization and assignment for structures.
End of story; I'm going to walk away pretend I never read this subthread, re-joining the hordes of C programmers using memset in the normal way, adding to the countless lines of code that do it that way and are never going to be changed.
This bullshit will be backpedaled out of the standard eventually, you just wait.
Which is to say that memset_s should just be called memset; there is no need for memset to be doing stupid things so that people must use memset_s.
I have no plans to use memset_s (ever), or to upstream any fix that involves using it unless the author provides a repro test case, and a proof that the problem can't be fixed with compiler options that make the problem go away with memset.
In the worst imaginable scenario, I will #define memset memset_s everywhere (after the inclusion of <string.h> of course, not before, and an #undef memset).
(The #undef memset may be enough, in fact, if the only problem is that memset is #define'd to some compiler built-in that doesn't properly implement classic C90 memset in all cases.)