> One possible side effect is that this now calls snprintf() instead of
> sprintf().  Whether or not this will cause yet another library routine
> to be pulled in I haven't checked.

snprintf isn't very big anyway - just a hook to vsnprintf, much
the same as sprintf - which uses -(size_t)buf as the length.

> The .XXX objects above revert to using
> 
> 	sprintf(ebuf, "Unknown error: code %d", err);
> 
> and is a little smaller (ignoring BSS).

Which may, or may not matter.

The ebuf[64] overruns when int is 128 bits (give or take a byte).
It probably ought to be a snprintf call anyway - then the buffer
size could safely be halfed.

	David

-- 
David Laight: david@l8s.co.uk