From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon,  9 Feb 2009 03:55:40 -0500
From: Nathaniel W Filardo <nwf@cs.jhu.edu>
To: 9fans@9fans.net
Message-ID: <20090209085540.GC22259@masters6.cs.jhu.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="xo44VMWPx7vlQ2+2"
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: [9fans] APE vsnprintf return value bug
Topicbox-Message-UUID: 9a160068-ead4-11e9-9d60-3106f5b1d025


--xo44VMWPx7vlQ2+2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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;

--xo44VMWPx7vlQ2+2
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmP74wACgkQTeQabvr9Tc8FygCfZkjZIgGyW1/HrcH6k4cuLxE/
ThQAn09XLj8/76gnoqJ/tNOX8qeVsd7p
=9IdX
-----END PGP SIGNATURE-----

--xo44VMWPx7vlQ2+2--