There seems to be some disagreement about vsnprintf()'s return code, in a way that's breaking my attempts to get git building on Plan 9.
The manual on my Linux box says:
> The functions snprintf() and vsnprintf() do not write more than size
> bytes (including the trailing '\0'). If the output was truncated due to
> this limit then the return value is the number of characters (not
> including the trailing '\0') which would have been written to the final
> string if enough space had been available. Thus, a return value of size
> or more means that the output was truncated. (See also below under
> NOTES.)
While this strikes me as funny (though I suppose I see the merit), git
depends upon it being this way... so when
/sys/src/ape/lib/ap/stdio/vfprintf.c says:
> int
> vfprintf(FILE *f, const char *s, va_list args)
> {
...
> return ferror(f)? -1: nprint;;
> }
It appears that all hope is lost. If I were to submit a patch which renamed
vfprintf to _vfprintf and pushed the ferror() check down to its callers,
would such a thing be accepted?
--nwf;
pgpft9ma62VXc.pgp
Description: PGP signature
