On 07.01.2014 22:21, Simo Sorce wrote:
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() ?
Sure ... done.
> 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.
It's the same interface as the functions being replaced: snprintf and
asprintf. We return the full format length, or -1 on failure. snprintf
and friends don't set errno. See man printf(3).
But I guess now that we're diverging from the interface provided by
snprintf and friends, I don't mind setting errno to EINVAL/ENOMEM if it
makes you happy.
Stef