please don't recommend strncat()

[loreb]

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

[loreb]

Hope you didn't take it the wrong way and please please please keep working on security.md!

[mcinglis]

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 :)

[loreb]

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.

[loreb]

Unrelated: typo in "%.20x" -- should be a string

[loreb]

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 :)