9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] APE vsnprintf return value bug
@ 2009-02-09  8:55 Nathaniel W Filardo
  2009-02-09  9:20 ` Steve Simon
  0 siblings, 1 reply; 3+ messages in thread
From: Nathaniel W Filardo @ 2009-02-09  8:55 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

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;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [9fans] APE vsnprintf return value bug
  2009-02-09  8:55 [9fans] APE vsnprintf return value bug Nathaniel W Filardo
@ 2009-02-09  9:20 ` Steve Simon
  2009-02-09 10:08   ` Charles Forsyth
  0 siblings, 1 reply; 3+ messages in thread
From: Steve Simon @ 2009-02-09  9:20 UTC (permalink / raw)
  To: 9fans

I don't have a copy of the ISO 9899:1990 but Plauger's The Standard C Library
has excerpts from it. In one of these it states:

	``The vfprintf function returns the number of characters transmitted,
	or a negative value if an output error occured''

As APE does take great pains to be standards conformant its a shame to break it here.

How about a _GLIBC_SOURCE define in the headers and a glibc_vfprintf() function
in the library?

Just my 2 cents worth.

-Steve



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [9fans] APE vsnprintf return value bug
  2009-02-09  9:20 ` Steve Simon
@ 2009-02-09 10:08   ` Charles Forsyth
  0 siblings, 0 replies; 3+ messages in thread
From: Charles Forsyth @ 2009-02-09 10:08 UTC (permalink / raw)
  To: 9fans

vfprintf should return the number of characters transmitted.
v?snprintf should return the number needed (excluding the nul terminator),
but the actual result varies (incorrectly) between systems.



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-02-09 10:08 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-09  8:55 [9fans] APE vsnprintf return value bug Nathaniel W Filardo
2009-02-09  9:20 ` Steve Simon
2009-02-09 10:08   ` Charles Forsyth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).