Kurt Roeckx <[EMAIL PROTECTED]> writes:
> Concerning the return value of snprintf(), the SUSv2 and the C99 stan-
> dard contradict each other:
Is that where the problem comes from?
Anyway, I've added some text to snprintf.c explaining what we do. Since
the calling code has to be prepared to handle either result convention,
I see no need to do anything except what's easiest to implement, which
in this case is the SUS behavior. (There's also a consistency issue,
which is that fprintf is supposed to return the number of bytes actually
transmitted, not the number it would have sent in the absence of error.)
regards, tom lane
* 5. Space and '#' flags are not implemented.
+ *
+ *
+ * The result values of these functions are not the same across different
+ * platforms. This implementation is compatible with the Single Unix Spec:
+ *
+ * 1. -1 is returned only if processing is abandoned due to an invalid
+ * parameter, such as incorrect format string. (Although not required by
+ * the spec, this happens only when no characters have yet been transmitted
+ * to the destination.)
+ *
+ * 2. For snprintf and sprintf, 0 is returned if str == NULL or count == 0;
+ * no data has been stored.
+ *
+ * 3. Otherwise, the number of bytes actually transmitted to the destination
+ * is returned (excluding the trailing '\0' for snprintf and sprintf).
+ *
+ * For snprintf with nonzero count, the result cannot be more than count-1
+ * (a trailing '\0' is always stored); it is not possible to distinguish
+ * buffer overrun from exact fit. This is unlike some implementations that
+ * return the number of bytes that would have been needed for the complete
+ * result string.
*/
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
