Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utfyzx!sq!msb
From: msb@sq.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: sprintf return value (was: String Processing Instruction)
Message-ID: <1987Mar30.143052.16783@sq.uucp>
Date: Mon, 30-Mar-87 14:30:52 EST
Article-I.D.: sq.1987Mar30.143052.16783
Posted: Mon Mar 30 14:30:52 1987
Date-Received: Tue, 31-Mar-87 05:33:03 EST
References: <6448@watmath.UUCP>
Reply-To: msb@sq.UUCP (Mark Brader)
Distribution: na
Organization: SoftQuad Inc., Toronto
Lines: 22
Xref: utgpu comp.arch:705 comp.lang.c:1381
Checksum: 42252
Summary: nonportable, but ANSI did it right

> > 	sprintf(p, "format%d%s", args...); p+= strlen(p);

> Wouldn't it have been nice if strcpy(), strcat(), sprintf(), etc.
> had been designed to return a pointer to the END of the string,
> (or a count of the number of characters in the string)?

In some C implementations, sprintf() DOES return a count of the number
of characters that it wrote.  I find this behavior in a System V manual,
for instance, and on VMS.

Since both behaviors existed, the ANSI people were able to choose the more
useful one, and the October 1986 draft mandates that sprintf() returns
a count.  Unfortunately this does not apply to the other string functions.

Also unfortunately, the new book "Portable C and UNIX System Programming"
by "J. E. Lapin" misses this one.  (That's why I had to check manuals...)

Meanwhile, until ANSI C is universal, we should all be careful NOT to assume
that we know what type sprintf() returns...

Mark Brader	      "Perhaps their software was written by a Byzan-tine-ager"
utzoo!sq!msb						      -- Peter Neumann