mcinglis
please don't recommend strncat()
Reason: it's too difficult to use correctly (among the many, many mistakes you will make, think of the meaning of the N parameter: it's how many characters you can append). Edit: see http://the-flat-trantor-society.blogspot.it/2012/03/no-strncpy-is-not-safer-strcpy.html for a more detailed explanation of what it was designed to do and how it's different from typical usage.
Better alternatives are OpenBSD's strlcat, or better(!!!) something like Microsoft' strcat_s/strncat_s -- it's better in that it returns wether an overflow occurred, so you can't make typos comparing to the wrong size; the downsize is that by default it aborts on overflow... An even simpler alternative imho is http://yarchive.net/comp/linux/strncpy.html
Hope you didn't take it the wrong way and please please please keep working on security.md!
Hey - thanks very much for your comments.
Because they're unfinished, I've moved the security notes into the feature/security branch.
I also updated the notes a bit to reflect what you and your links say (I agree; the Annex K functions rock!).
https://github.com/mcinglis/c-style/blob/feature/security/security.md
It would be cool to hear your thoughts on these new recommendations. C string handling is so hard :)
Looks ok, and prompted me to check -- I have eglibc, musl and dietlibc installed, and none of them have strcpy_s and friends :( Btw, about strings: there's a document (+ two libraries + thorough review of other libraries) arguing a radically different approach at http://www.and.org/vstr/security; I'm glad I've never found myself needing to go to these extremes but I've always found it some of the best read on the subject.
Unrelated(2): copy_string should return size_t, as at least on x86_64 they have a different size (I can't imagine someone copying strings that big, but even djb fell into that, see http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html). To be fair, I didn't notice that as well -- I just tried to compile your examples and got these two warnings from clang :)