sprintf_s() syntax?

[Sams Lara]

Does anybody know how to make use of sprintf_s() for this small function?

void sendOutput(double* arr, int yrs) {
    char outstring[100];
    int i;

    printf("\nRESULTS: \n\n");

    for (i = 0; i < yrs; i++)
    {
        sprintf(outstring, "Year %3d:  %10.2f\n", i, arr[i]);
        // printf("Year %3d:  %10.2f\n", i, arr[i]);
        printf("%s", outstring);
    }
    printf("\n");
}

When I am using sprintf() as shown above, it works but when I try to
make use of sprintf_s() (for latest versions of compilers) it prints
nothing so where am I going wrong? I know it is the syntax problem and I
am stuck with this. The code I have tried is:

sprintf_s(outstring, "Year %3d:  %10.2f\n", i, arr[i]);

The outstring is an array of 100 characters as shown in the function but
how do I make use of it in the code (if at all it is necessary).  the
example given here is a bit confusing:

<https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/sprintf-s-sprintf-s-l-swprintf-s-swprintf-s-l?view=msvc-170>

As I understand it, sprintf() is deprecated so modern compilers gives
error message. I am using VS 2022 from Microsoft.

[Joe Pfeiffer]

You aren't passing it the second parameter. You should be calling it as

sprintf_s(outstring, 100, "Year %3d:  %10.2f\n", i, arr[i]);

or, better

sprintf_s(outstring, sizeof(outstring), "Year %3d:  %10.2f\n", i, arr[i]);

[James Kuyper]

On 4/1/22 22:00, Sams Lara wrote:
> Does anybody know how to make use of sprintf_s() for this small function?
>
> void sendOutput(double* arr, int yrs) {
>     char outstring[100];
>     int i;
>
>     printf("\nRESULTS: \n\n");
>
>     for (i = 0; i < yrs; i++)
>     {

>         sprintf(outstring, "Year %3d:  %10.2f\n", i, arr[i]);...

> sprintf_s(outstring, "Year %3d:  %10.2f\n", i, arr[i]);

The thing that makes sprintf_s() different from sprintf() (and
supposedly safer to use) is that sprintf() takes one additional argument
of type rsize_t (which is the same type as size_t) after the format
string, which is the maximum number of characters that should be printed
by sprintf_s() to the output string. You should be passing `sizeof
outstring` for that argument.

Instead, you're passing it 'i' as its third argument, which is likely to
be the wrong size. Even if it were the right size, sprintf_s() would
then try to interpret arr[i] as an int to match "%3d". Even if that
worked, it would then go on to try to find a match for "%10.2f", and you
haven't provided one.

...

> As I understand it, sprintf() is deprecated so modern compilers gives
> error message. I am using VS 2022 from Microsoft.

Microsoft deprecates sprintf(), the C standard does not.

[Joe Pfeiffer]

James Kuyper <james...@alumni.caltech.edu> writes:

> On 4/1/22 22:00, Sams Lara wrote:
>> Does anybody know how to make use of sprintf_s() for this small function?
>>
>> void sendOutput(double* arr, int yrs) {
>>     char outstring[100];
>>     int i;
>>
>>     printf("\nRESULTS: \n\n");
>>
>>     for (i = 0; i < yrs; i++)
>>     {
>>         sprintf(outstring, "Year %3d:  %10.2f\n", i, arr[i]);...
>> sprintf_s(outstring, "Year %3d:  %10.2f\n", i, arr[i]);
>
> The thing that makes sprintf_s() different from sprintf() (and
> supposedly safer to use) is that sprintf() takes one additional argument
> of type rsize_t (which is the same type as size_t) after the format
> string, which is the maximum number of characters that should be printed
> by sprintf_s() to the output string. You should be passing `sizeof
> outstring` for that argument.

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/sprintf-s-sprintf-s-l-swprintf-s-swprintf-s-l?view=msvc-170
says the size of the output buffer is the second argument, going before
the format string.

[Manfred]

On 4/2/2022 4:00 AM, Sams Lara wrote:
> Does anybody know how to make use of sprintf_s() for this small function?
>
> void sendOutput(double* arr, int yrs) {
>     char outstring[100];
>     int i;
>
>     printf("\nRESULTS: \n\n");
>
>     for (i = 0; i < yrs; i++)
>     {
>         sprintf(outstring, "Year %3d:  %10.2f\n", i, arr[i]);
>         // printf("Year %3d:  %10.2f\n", i, arr[i]);
>         printf("%s", outstring);
>     }
>     printf("\n");
> }
>
> When I am using sprintf() as shown above, it works but when I try to
> make use of sprintf_s() (for latest versions of compilers) it prints
> nothing so where am I going wrong? I know it is the syntax problem and I
> am stuck with this. The code I have tried is:
>
> sprintf_s(outstring, "Year %3d:  %10.2f\n", i, arr[i]);

If it is a syntax problem the compiler should have given an error
message that would tell what is wrong.

>
> The outstring is an array of 100 characters as shown in the function but
> how do I make use of it in the code (if at all it is necessary).  the
> example given here is a bit confusing:
>
> <https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/sprintf-s-sprintf-s-l-swprintf-s-swprintf-s-l?view=msvc-170>

As others have pointed out, you need to pass in the length of the buffer
as the second argument:

sprintf_s(outstring, 100, "Year %3d: %10.2f\n", i, arr[i]);

You should have got an error message if you compiled the call as you
showed above in C mode.

MS also provides a templated C++ version that is able to infer the array
size when passed in a C-style array buffer, wherein you don't need to
explicitly pass in the size of the buffer. This version would be used
only if compiled in C++ mode.

>
> As I understand it, sprintf() is deprecated so modern compilers gives
> error message. I am using VS 2022 from Microsoft.
>

You shouldn't get an error message for using sprintf. You probably get
some warning.

sprintf and friends are deprecated by recent Microsoft compilers. They
are not deprecated by other compilers, for example glibc with gcc.
In fact the family of "_s" functions belong to Annex K of the C
standard, which is optional for implementations, and somewhat
controversial, in the sense that some vendors (e.g. the GNU people) do
not consider it a good solution for the problem it is supposed to solve.

[Ben Bacarisse]

Sams Lara <samla...@gmail.com> writes:

> void sendOutput(double* arr, int yrs) {
>     char outstring[100];
>     int i;
>
>     printf("\nRESULTS: \n\n");
>
>     for (i = 0; i < yrs; i++)
>     {
>         sprintf(outstring, "Year %3d:  %10.2f\n", i, arr[i]);
>         // printf("Year %3d:  %10.2f\n", i, arr[i]);
>         printf("%s", outstring);
>     }
>     printf("\n");
> }
>
> When I am using sprintf() as shown above, it works but when I try to
> make use of sprintf_s() (for latest versions of compilers) it prints
> nothing so where am I going wrong? I know it is the syntax problem and I
> am stuck with this. The code I have tried is:
>
> sprintf_s(outstring, "Year %3d:  %10.2f\n", i, arr[i]);

I think you have all the answers you need about sprintf_s, but no one
seems to have mentioned the standard function snprintf. It is similar
to sprintf_s, though the latter does more run-time checks. sprintf_s is
also sort of standard C, but it's part of Annex K which is optional.

--
Ben.

[Öö Tiib]

Usage of snprintf is good advice as Annex K is optional. Even
MS itself implemented it with differences.
Also it is unsure if that constraint_handler makes it simpler or
more confused to find programming errors.

[Andrey Tarasevich]

On 4/1/2022 7:00 PM, Sams Lara wrote:
> make use of sprintf_s() (for latest versions of compilers) it prints
> nothing so where am I going wrong? I know it is the syntax problem and I
> am stuck with this. The code I have tried is:

Firstly, I don't see `sprintf_s` in your code. Why are you asking a
question about `sprintf_s` and suppling code that doesn't have
`sprintf_s` in it?

Secondly, if you simply replaced `sprintf` with `sprintf_s` your code
became invalid. Your compiler clearly told you where the problem is by
issuing a diagnostic message. Why did you decide to ignore that
diagnostic message and ask an abstract question here instead? (And here
you don't even mention the diagnostic message.)

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

OK, I missed this part

> The code I have tried is:

> sprintf_s(outstring, "Year %3d: %10.2f\n", i, arr[i]);

But my "secondly" still stands.

[James Kuyper]

He said "when I try to make use of sprintf_s() (for latest versions of
compilers) it prints nothing". This means that he successfully compiled
and linked the code, and suggests that he might not have seen any
diagnostics. There are ways to make that happen, for instance by
compiling the code in C90 mode while linking to a library containing
sprintf_s().

[Manfred]

This is close to what happens with the MSVC compiler. I tried it on my
installation, and it gave a bunch of warnings, but it still compiled and
linked the code.
Incidentally, in my case it also prints nothing, but that's obviously UB
in action.

[Andrey Tarasevich]

Well, that's the problem I'm trying to point out. I'm confident that a
diagnostic message was emitted by the compiler, but he might not have
seen it simply because he wasn't paying attention.

Many C compilers are traditionally/historically configured to report
certain kinds of hard "errors" as "warnings" by default. And this is
often the reason inexperienced users often take careless and dismissive
attitude to such diagnostic messages.

Supplying an argument of incorrect type to a prototyped function is a
hard error in C (http://port70.net/~nsz/c/c11/n1570.html#6.5.2.2p2).

If the diagnostic message is one of those required by the standard (e.g.
a constraint violation), then the code *isn't* officially considered
"successfully compiled and linked". Whatever executable an
implementation produces in such cases is considered a "garbage temporary
output file" the implementation simply "forgot" to clean up after
translation.

[Sams Lara]

On 02/04/2022 03:00, Sams Lara wrote:
> Does anybody know how to make use of sprintf_s() for this small function?

Thank you all for the constructive comments and suggestions on this
topic. The program now runs and as you have all noticed that one
parameter was missing that I was stuck with. The Program now runs after
inserting that parameter as suggested by you experts and you can try
this small program, the code is here (3 files - main.c, header file,
functions file). Just input these figures to test it:

10000 1.05 10


<============================================================>
// This is the main Program: main.c
#include <stdio.h>
#include "HelperHeader.h"

int main(void)
{
    Investment inv;

    while (getUserInput(&inv))
    {
        inv.invarray[0] = inv.inv0;
        calculateGrowth(&inv);
        sendOutput(inv.invarray, inv.years);
    }
    return 0;
}
<============================================================>
// This is the functions file called functions.c

#include <stdio.h>
#include "HelperHeader.h"

void calculateGrowth(Investment* invp) {
    for (int i = 1; i < invp->years; i++) {
        invp->invarray[i] = invp->growth * invp->invarray[i - 1];
    }
}

int getUserInput(Investment* invp) {
    int valid;

    printf("Enter investment, growth rate, number of years (upto %d):
", MAX_YEARS);
    scanf_s("%lf %lf %d", &(invp->inv0), &(invp->growth), &(invp->years));
    valid = (invp->inv0 > 0) && (invp->growth > 0) && (invp->years > 0)
&& (invp->years <= MAX_YEARS);

    printf("Valid input? %d\n", valid);

    if (!valid) {
        printf("Invalid Input: exiting.\n");
    }
    return valid;

}

void sendOutput(double* arr, int yrs) {
    char outstring[100];

    printf("\nRESULTS: \n\n");

    for (int i = 0; i <= yrs; i++)
    {
        sprintf_s(outstring, (unsigned)sizeof(outstring), "Year %3d: 

%10.2f\n", i, arr[i]);

        // printf("Year %3d:  %10.2f\n", i, arr[i]);
        printf("%s", outstring);
    }
    printf("\n");
}

<============================================================>
// This is the header file called: "HelperHeader.h"
#pragma once
#include <stdio.h>

#define MAX_YEARS 100


typedef struct {
    double inv0;
    double growth;
    int years;
    double invarray[MAX_YEARS + 1];
}Investment;

int getUserInput(Investment* invp);
void calculateGrowth(Investment* invp);
void sendOutput(double* arr, int years);
<============================================================>

[James Kuyper]

On 4/4/22 13:32, Andrey Tarasevich wrote:
> On 4/4/2022 8:20 AM, James Kuyper wrote:
>> On 4/4/22 00:24, Andrey Tarasevich wrote:
>>> On 4/3/2022 9:23 PM, Andrey Tarasevich wrote:

...

>>>> Secondly, if you simply replaced `sprintf` with `sprintf_s` your code
>>>> became invalid. Your compiler clearly told you where the problem is by
>>>> issuing a diagnostic message. Why did you decide to ignore that
>>>> diagnostic message and ask an abstract question here instead? (And here
>>>> you don't even mention the diagnostic message.)
>>>>
>>>
>>> OK, I missed this part
>>>
>>>> The code I have tried is:
>>>> sprintf_s(outstring, "Year %3d: %10.2f\n", i, arr[i]);
>>>
>>> But my "secondly" still stands.
>>>
>>
>>
>> He said "when I try to make use of sprintf_s() (for latest versions of
>> compilers) it prints nothing". This means that he successfully compiled
>> and linked the code, and suggests that he might not have seen any
>> diagnostics.
>
> Well, that's the problem I'm trying to point out. I'm confident that a
> diagnostic message was emitted by the compiler, but he might not have
> seen it simply because he wasn't paying attention.

That's one possibility, but I was pointing out that another possibility
is that no diagnostic message was emitted, due to his choice of compiler
and compilation options.

> Many C compilers are traditionally/historically configured to report
> certain kinds of hard "errors" as "warnings" by default. And this is
> often the reason inexperienced users often take careless and
> dismissive attitude to such diagnostic messages.
>
> Supplying an argument of incorrect type to a prototyped function is a
> hard error in C (http://port70.net/~nsz/c/c11/n1570.html#6.5.2.2p2).

I think "mandatory diagnostic" is a better term than "hard error".
"Hard error" might be misinterpreted as implying that a conforming
implementation of C is required to reject such a program.

I mentioned the possibility that he was compiling in C90 mode, precisely
because C90 didn't have prototypes, and a function could be called
without a declaration in scope - no diagnostic was required.

A compiler option that turns off that mandatory diagnostic would render
it non-conforming to C99 and later, but there's nothing unusual about C
compilers having options that render them non-conforming.

> If the diagnostic message is one of those required by the standard
> (e.g. a constraint violation), then the code *isn't* officially
> considered "successfully compiled and linked".

I consider a program to have been "successfully compiled and linked" if
compilation results in a linkable object file, and if linkage results in
an executable program. The fact that a diagnostic is mandatory does not
prohibit either of those outcomes.

> ... Whatever executable an implementation produces in such cases is

> considered a "garbage temporary output file" the implementation simply
> "forgot" to clean up after translation.

No, in many cases implementations will take code for which a diagnostic
is mandatory, translate it in a way the implementor considers useful,
and generate an executable that will produce that useful behavior when
executed. In some cases, this useful behavior is a documented extension.

Allowing code that calls a undeclared function to be compiled the same
way it would have been in C90 would be an example of such "useful
behavior". Such a program could be linkable with module containing an
external definition for that function, if the types of the function's
parameters declared in the function definition are compatible with the
promoted types of the corresponding function call arguments, and the
return type is `int`.

If I see such a mandatory diagnostic, I wouldn't bother trying to use
the resulting executable, but I know that it's entirely possible that
the resulting executable might actually be executable, and might have
reasonable behavior (not necessarily the behavior I wanted), even though
the standard does not require that this be the case.

[Andrey Tarasevich]

On 4/4/2022 9:08 PM, James Kuyper wrote:
>
>> Many C compilers are traditionally/historically configured to report
>> certain kinds of hard "errors" as "warnings" by default. And this is
>> often the reason inexperienced users often take careless and
>> dismissive attitude to such diagnostic messages.
>>
>> Supplying an argument of incorrect type to a prototyped function is a
>> hard error in C (http://port70.net/~nsz/c/c11/n1570.html#6.5.2.2p2).
>
> I think "mandatory diagnostic" is a better term than "hard error".
> "Hard error" might be misinterpreted as implying that a conforming
> implementation of C is required to reject such a program.

I don't know and, frankly, don't care how someone cam "misinterpret"
something out of the blue. Standard C language does not ever require
rejection, aside perhaps from an active `#error` directive.

>> If the diagnostic message is one of those required by the standard
>> (e.g. a constraint violation), then the code *isn't* officially
>> considered "successfully compiled and linked".
>
> I consider a program to have been "successfully compiled and linked" if
> compilation results in a linkable object file, and if linkage results in
> an executable program. The fact that a diagnostic is mandatory does not
> prohibit either of those outcomes.

I don't. This is like relying on values in uninitialized storage.
Someone might claim that is always "successfuly zero" in their
experiments and even substantiate with some sort of
implementation-specific direct or indirect guarantees, but this is not C.

>> ... Whatever executable an implementation produces in such cases is
>> considered a "garbage temporary output file" the implementation simply
>> "forgot" to clean up after translation.
>
> No, in many cases implementations will take code for which a diagnostic
> is mandatory, translate it in a way the implementor considers useful,
> and generate an executable that will produce that useful behavior when
> executed. In some cases, this useful behavior is a documented extension.

_Only_ when this useful behavior is a documented extension. But even in
that case this still goes beyond C and transgress into the area of some
implementation-specific language. An implementation might even translate
Pascal code as part of their C implementation.

But this is beside the point anyway. This is just pumping smoke into the
topic. We all know what happened in the OP's code. We aren't dealing
with an extension in this case.

> Allowing code that calls a undeclared function to be compiled the same
> way it would have been in C90 would be an example of such "useful
> behavior". Such a program could be linkable with module containing an
> external definition for that function, if the types of the function's
> parameters declared in the function definition are compatible with the
> promoted types of the corresponding function call arguments, and the
> return type is `int`.

This remark is unnecessary, but still: in this case we are dealing with
a variadic function. Even in C90 variadic functions require a prototype
before the call. Calling an unprototyped varidic function leads to
undefined behavior. I does not require a diagnostic, of course, but
still it does not formally result in a useful behavior either.