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.
--
Simo Sorce * Red Hat, Inc * New York