On Tue, 2014-01-07 at 21:31 +0100, Stef Walter wrote:
On 07.01.2014 20:34, Simo Sorce wrote:
Ok fine, makes sense once explained (need this explanation in the docs/headers), but then use a different name.
If I see safe_snprintf, I assume the full format capabilities of snprintf, the name in this case is misleading.
That said I am not sure what's the best name you could use... maybe strextend ? and the astrextend variant for allocated ones ?
I've called it safe_str_snprintf (and so on). Hopefully that's clear enough. It is processing the familiar printf syntax, so it makes sense to have that somewhere.
Personally the problem is in using 'printf' in there (both in function name and file names), because although similar it doesn't support all of printf semantics, and it can't, it will confuse peole. I do not think a _str_ prefix really makes a difference. The other issue is that you may later find people "extending" safe_snprintf() to "support the other format arguments" and we are back to an "unsafe" function.
Maybe: safe_format_string() ?
Updated header documentation as requested, and made other fixes from your earlier review.
Sorry I forgot another, I think you should either set errno on errors, or return an errno_t instead of -1. Just returning -1 for all errors is a poor interface.
The rest looks good to me.
Simo.