Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

swprintf vs snprintf

469 views
Skip to first unread message

mike burrell

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to
in my copy of n869, swprintf() is described as returning:
[#3] The swscanf function returns the value of the macro EOF
if an input failure occurs before any conversion.
Otherwise, the swscanf function returns the number of input
items assigned, which can be fewer than provided for, or
even zero, in the event of an early matching failure.

however, a very similar function, snprintf() (which is near identical,
except it works with strings instead of wide strings) returns:
[#3] The snprintf function returns the number of characters
that would have been written had n been sufficiently large,
not counting the terminating null character, or a negative
value if an encoding error occurred. Thus, the null-
terminated output has been completely written if and only if
the returned value is nonnegative and less than n.

the discrepancy i'm trying to point out is the value that is returned if 'n'
(which is conventionally to represent the length of the buffer) is smaller
than the total number of theoretical characters written. i must say that i
was impressed snprintf() when i first saw it, as it meant that for strings
whose length could not be calculated (or was very hard to calculate)
beforehand, such as with encoding floating-point numbers, only two calls to
snprintf() were necessary. however, the definition of swprintf() seems to
be near identical to the old Unix way of doing snprintf(), which was not
very helpful (in some instances you just had to put it in a realloc() loop).

so i'm asking whether swprintf() (and vswprintf()) were changed in the final
release of C99, and hopefully some rationale on why these two functions
behave so differently :).

cheers

--
/"\ m i k e b u r r e l l
\ / ASCII RIBBON CAMPAIGN mik...@home.com
X AGAINST HTML MAIL,
/ \ AND NEWS TOO, dammit

Douglas A. Gwyn

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to
mike burrell wrote:
> in my copy of n869, swprintf() is described as returning:
> [#3] The swscanf function ...

Wrong description; let's assume the one for swprintf.

> however, a very similar function, snprintf() (which is

> near identical, ...

The analog of swprintf is sprintf, not snprintf.

Your observation boils down to: There is no snwprintf.
That is true, but I forget whether it was overlooked
when we added snprintf, or intentionally not supported.
I seem to recall that Peter Seebach was the principal
proponent of snprintf, so maybe he remembers.

Paul Jarc

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to
"Douglas A. Gwyn" <gw...@arl.army.mil> writes:
> The analog of swprintf is sprintf, not snprintf.

By name, but not by interface. According to n869, swprintf takes an
argument specifying the size of the buffer it's writing to, like
snprintf and unlike sprintf, but doesn't return the analogous useful
information.


paul

Larry Jones

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to
mike burrell (mik...@home.com) wrote:
>
> so i'm asking whether swprintf() (and vswprintf()) were changed in the final
> release of C99, and hopefully some rationale on why these two functions
> behave so differently :).

No, they didn't change in the final version. There was prior art for
snprintf() returning the required number of characters and we recognized
the value of doing that, so that's the specification we adopted even
though it was different than swprintf(). Since swprintf() was already a
standard function, we didn't think it was right to make an incompatible
change to its interface, and the different return value didn't seem to
be important enough to justify adding yet another library function.

-Larry Jones

It works on the same principle as electroshock therapy. -- Calvin

Clive D.W. Feather

unread,
Jul 9, 2000, 3:00:00 AM7/9/00
to
In article <8k2vn3$d...@nfs0.sdrc.com>, Larry Jones
<scj...@thor.sdrc.com> writes

>No, they didn't change in the final version. There was prior art for
>snprintf() returning the required number of characters and we recognized
>the value of doing that, so that's the specification we adopted even
>though it was different than swprintf(). Since swprintf() was already a
>standard function, we didn't think it was right to make an incompatible
>change to its interface, and the different return value didn't seem to
>be important enough to justify adding yet another library function.

You also need to be aware of the history: swprintf() was added in C94,
whereas snprintf() only just got in to the later drafts of C99. I don't
even recall if anyone noticed the discrepancy.

--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | Thus plc | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address

Antoine Leca

unread,
Jul 10, 2000, 3:00:00 AM7/10/00
to
Clive D.W. Feather wrote:
>
> You also need to be aware of the history: swprintf() was added in C94,
> whereas snprintf() only just got in to the later drafts of C99. I don't
> even recall if anyone noticed the discrepancy.

This very point (swprintf vs snprintf) have already been exposed here
two times... (or was it on the reflector once?)

Now, if you are talking about the discrepancy between the "invented"
swprintf() and the already existing snprintf(), back in 1993 or so when
MSE were drafted, or in ~1994 when the modified prototype was adopted,
I was not there, but it looks like quite plausible.


Antoine

0 new messages