From: Guy Harris
| On Sat, May 01, 2004 at 11:29:49PM +0200, Olivier Biot wrote:
| > As we're using GLib, does anyone object if I get rid of snprintf
in
| > the code?
|
| Note the comment
|
| Note: In versions of GLib prior to 1.2.3, this function may
| return -1 if the output was truncated, and the truncated string
| may not be NULL-terminated.
|
| in the "g_snprintf()" and "g_vsnprintf()" documentation.
I was not aware of those.
| It looks as if 1.2.10 (and presumably 1.2.3 and intermediate
releases)
| fixes that by checking whether the underlying "snprintf()" or
| "vsnprintf()" routine returns a negative value and, if so,
| null-terminates the string and returns the string length. That
seems to
| imply that the behavioral difference between pre-1.2.3 and 1.2.3
| reflects differences between "snprintf()" implementations, in which
case
| we might already cope with that problem.
|
| Note also that, for systems lacking "snprintf()", it uses the
| "g_strdup_vprintf()" routine, so that's perhaps a little less
efficient
| than the replacement "snprintf()" - but I'm not sure what platforms
lack
| it, other than Digital UNIX, so maybe that's not an issue.
|
| I also don't know whether we anywhere assume that the return value
of
| "snprintf()" is the number of characters the string *would* have
taken
| if it *hadn't* overflowed the buffer - probably not, given that we
can't
| even assume that it returns anything other than -1 if we overflow
the
| buffer.
In other words it might be an even better idea to use "our" snprintf
method instead of the one either provided by the OS or by GLIb?
Regards,
Olivier
