snprintf and snprintf_s

[jacob navia]

snprintf accepts a buffersize of zero and a null buffer pointer. That
means that snprintf is used to just calculate the number of characters
that would be required by the given format string and arguments.

Now snprintf_s however REQUIRES that the buffer is never NULL and that n
is always bigger than zero.

Why this discrepancy?

In general the _s functions are just the same functions as their
"normal" counterparts with extra checks. Why this difference here?

Or is it just a bug?

 

[Stefan Ram]

snprintf accepts a buffersize of zero and a null buffer pointer. That
means that snprintf is used to just calculate the number of characters
that would be required by the given format string and arguments.
Now snprintf_s however REQUIRES that the buffer is never NULL and that n
is always bigger than zero.

It provides the safety of not overflowing the buffer.
If there is no buffer, there is little additional safety,
and one can use »snprintf«. This way, if there is a buffer
pointer provided to »snprintf_s«, there is the additional
benefit of checking that the buffer pointer is not 0.

The documentation in N1570 K.3.5.3.5 seems to imply that n
gives the size of the buffer, but it does not seem to say this.

 

[Stefan Ram]

The documentation in N1570 K.3.5.3.5 seems to imply that n
gives the size of the buffer, but it does not seem to say this.

The documentation in N1570 »K.3.5.3.6 The sprintf_s function« contains:

»The number of characters (including the trailing null)
required for the result to be written to the array
pointed to by s shall not be greater than n.«

, but this is missing here in »K.3.5.3.5 The snprintf_s function«.

 

[Bill Cunningham]

snprintf accepts a buffersize of zero and a null buffer pointer. That
means that snprintf is used to just calculate the number of characters
that would be required by the given format string and arguments.

Now snprintf_s however REQUIRES that the buffer is never NULL and that n
is always bigger than zero.

Why this discrepancy?

In general the _s functions are just the same functions as their "normal"
counterparts with extra checks. Why this difference here?

Or is it just a bug?

http://www.lmgtfy.com/?q=n1570

 

[Ben Bacarisse]

snprintf accepts a buffersize of zero and a null buffer pointer. That
means that snprintf is used to just calculate the number of characters
that would be required by the given format string and arguments.

Now snprintf_s however REQUIRES that the buffer is never NULL and that
n is always bigger than zero.

Why this discrepancy?

In general the _s functions are just the same functions as their
"normal" counterparts with extra checks. Why this difference here?

What is "this difference"? There are differences between snprintf and
snprintf_s, but the ability to calculate the number of characters
required to write the result is not one of them -- you just have to pass
something like

snprintf_s(&(char){0}, 1, ...)

rather than using a null pointer and zero.

<snip>

 

[jacob navia]

Le 27/04/2014 04:01, Ben Bacarisse a écrit :

What is "this difference"? There are differences between snprintf and
snprintf_s, but the ability to calculate the number of characters
required to write the result is not one of them -- you just have to pass
something like

snprintf_s(&(char){0}, 1, ...)

rather than using a null pointer and zero.

<snip>

Well that's precisely the difference!

I have to pass a dummy pointer and a dummy length to satisfy the
requirements. Why doesn't snprintf_s support the same interface as the
"normal" function?

The point is that you may be want to #define snprintf snprintf_s as you
may define fprintf as fprintf_s since the requirements are identical.

Now you have to memorize that the "_s" version of the function is NOT a
real replacement for the normal function and keep a different interface
for each one, a mess.

 

[Ian Collins]

I have to pass a dummy pointer and a dummy length to satisfy the
requirements. Why doesn't snprintf_s support the same interface as the
"normal" function?

Try asking Microsoft, they invented it!

 

[Ben Bacarisse]

Le 27/04/2014 04:01, Ben Bacarisse a écrit :

Well that's precisely the difference!

I have to pass a dummy pointer and a dummy length to satisfy the
requirements. Why doesn't snprintf_s support the same interface as the
"normal" function?

I can't say, but I was confused by your singling out of snprintf_s.
Many of the _s functions are quite different to the "normal" ones. In
that sense, snprintf_s does not stand out.

The point is that you may be want to #define snprintf snprintf_s as
you may define fprintf as fprintf_s since the requirements are
identical.

Now you have to memorize that the "_s" version of the function is NOT
a real replacement for the normal function and keep a different
interface for each one, a mess.

Yes, a mess. strcat_s is not a replacement for strcat. getenv_s is
very different to getenv, ctime_s can't be used as a macro replacement
for ctime... The list is huge. In fact, if fprint_s can be so used,
(the %n difference makes this unlikely) then it looks like the exception
rather than the rule.