Many times I need to construct a string through a call to sprintf and
pass it to an external function.

char s[32];
sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
lcd_write(s);

The size of s is fixed and calculated for the maximum length of
yourname, that is 9.

Later in time, I need to change the message into:

sprintf(s, "Hello %s, today is %d/%d/%d", yourname, day, month, year);

Of course, I need to re-calculate the worst-case length, that should be
now 35. However this is error-prone and I could forget to change the
size of array.

Is there a better way to manage this situation? I can't use malloc()
because I'm on an embedded system where I can't use heap.

I'm thinking to use sprintf(NULL, ...), such as:

const char fmt[] = "Hi %s, today is %d/%d/%d";
size_t n = sprintf(NULL, fmt, yourname, day, month, year);
char s[n + 1];
sprintf(s, fmt, yourname, day, month, year);
lcd_write(s);

Il 17/11/2021 11:36, pozz ha scritto:
> Many times I need to construct a string through a call to sprintf and
> pass it to an external function.
>
>   char s[32];
>   sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>   lcd_write(s);
>
> The size of s is fixed and calculated for the maximum length of
> yourname, that is 9.
>
> Later in time, I need to change the message into:
>
>   sprintf(s, "Hello %s, today is %d/%d/%d", yourname, day, month, year);
>
> Of course, I need to re-calculate the worst-case length, that should be
> now 35. However this is error-prone and I could forget to change the
> size of array.
>
> Is there a better way to manage this situation? I can't use malloc()
> because I'm on an embedded system where I can't use heap.
>
> I'm thinking to use sprintf(NULL, ...), such as:

I'm sorry, I mean:

snprintf(NULL, 0, ...)

On Wednesday, 17 November 2021 at 10:36:53 UTC, pozz wrote:
> Many times I need to construct a string through a call to sprintf and
> pass it to an external function.
>
> char s[32];
> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
> lcd_write(s);
>
> The size of s is fixed and calculated for the maximum length of
> yourname, that is 9.
>
> Later in time, I need to change the message into:
>
> sprintf(s, "Hello %s, today is %d/%d/%d", yourname, day, month, year);
>
> Of course, I need to re-calculate the worst-case length, that should be
> now 35. However this is error-prone and I could forget to change the
> size of array.
>
> Is there a better way to manage this situation? I can't use malloc()
> because I'm on an embedded system where I can't use heap.
>
> I'm thinking to use sprintf(NULL, ...), such as:
>
> const char fmt[] = "Hi %s, today is %d/%d/%d";
> size_t n = sprintf(NULL, fmt, yourname, day, month, year);
> char s[n + 1];
> sprintf(s, fmt, yourname, day, month, year);
> lcd_write(s);
>
That's a reasonable solution, as long as you know you have enough stack
(and a C99 compiler).
You've got to ask how likely it is that a bug whereby you overrun the buffer
will persist. If a bug will be caught in the first informal test, then it's not
dangerous. If it could slip through until a late stage, it's more worrying.
Since a buffer overrun will corrupt the variable immediately after the
buffer in memory, this might be detected immediately, or it might not be detected
for some time, depending on what that variable is used for. So a dangerous
bug, unless you've got some memory-checking software that can detect
such situations.
That's your best answer, however the software might be very expensive, or
might not be available at all.

On 17/11/2021 11:36, pozz wrote:
> Many times I need to construct a string through a call to sprintf and
> pass it to an external function.
>
>   char s[32];
>   sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>   lcd_write(s);
>
> The size of s is fixed and calculated for the maximum length of
> yourname, that is 9.
>
> Later in time, I need to change the message into:
>
>   sprintf(s, "Hello %s, today is %d/%d/%d", yourname, day, month, year);
>
> Of course, I need to re-calculate the worst-case length, that should be
> now 35. However this is error-prone and I could forget to change the
> size of array.
>
> Is there a better way to manage this situation? I can't use malloc()
> because I'm on an embedded system where I can't use heap.
>
> I'm thinking to use sprintf(NULL, ...), such as:
>
>   const char fmt[] = "Hi %s, today is %d/%d/%d";
>   size_t n = sprintf(NULL, fmt, yourname, day, month, year);
>   char s[n + 1];
>   sprintf(s, fmt, yourname, day, month, year);
>   lcd_write(s);
>

That would work (with your follow-up correction). You might want to put
a limit on "n" to avoid accidental stack overflow. This arrangement
does mean that you are doing the printf part twice.

Very often in small systems you know there is a maximum size - if your
screen is 40 characters wide, then 40 characters is enough in your
array. And if you might need up to 40 characters then you might as well
use all of the 40 chars, even though your string might be shorter - you
really don't want to test your code for the name "Al" on date 1/2/2021
and then find you have a stack overflow on 10/10/2021 with the name
"Rhoshandiatellyneshiaunneveshenk". (Apparently that's a real name -
according to google!)

It is also worth noting that only one task should be calling lcd_write
at a time - otherwise your display will be messed up. You can extend
that and say that only one task will be using the format buffer at a
time, and then it can be a statically array that is shared by all client
code.

On Wednesday, November 17, 2021 at 7:36:53 AM UTC-3, pozz wrote:
> Many times I need to construct a string through a call to sprintf and
> pass it to an external function.
>
> char s[32];
> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
> lcd_write(s);
>
> The size of s is fixed and calculated for the maximum length of
> yourname, that is 9.
>
> Later in time, I need to change the message into:
>
> sprintf(s, "Hello %s, today is %d/%d/%d", yourname, day, month, year);
>
> Of course, I need to re-calculate the worst-case length, that should be
> now 35. However this is error-prone and I could forget to change the
> size of array.
>
> Is there a better way to manage this situation? I can't use malloc()
> because I'm on an embedded system where I can't use heap.
>
> I'm thinking to use sprintf(NULL, ...), such as:
>
> const char fmt[] = "Hi %s, today is %d/%d/%d";
> size_t n = sprintf(NULL, fmt, yourname, day, month, year);
> char s[n + 1];
> sprintf(s, fmt, yourname, day, month, year);
> lcd_write(s);

See : asprintf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1248.pdf

This function is not implemented in some systems but it can be
built with other printf functions.

There is also open_memstream that I wish were part of C standard
because It cannot be implemented on windows without access to FILE internals.
https://linux.die.net/man/3/open_memstream

I create my own memory stream to be possible to use on windows and linux.

On 17/11/2021 10:36, pozz wrote:
> Many times I need to construct a string through a call to sprintf and
> pass it to an external function.
>
>   char s[32];
>   sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>   lcd_write(s);
>
> The size of s is fixed and calculated for the maximum length of
> yourname, that is 9.
>
> Later in time, I need to change the message into:
>
>   sprintf(s, "Hello %s, today is %d/%d/%d", yourname, day, month, year);
>
> Of course, I need to re-calculate the worst-case length, that should be
> now 35. However this is error-prone and I could forget to change the
> size of array.
>
> Is there a better way to manage this situation? I can't use malloc()
> because I'm on an embedded system where I can't use heap.
>
> I'm thinking to use sprintf(NULL, ...), such as:
>
>   const char fmt[] = "Hi %s, today is %d/%d/%d";
>   size_t n = sprintf(NULL, fmt, yourname, day, month, year);
>   char s[n + 1];
>   sprintf(s, fmt, yourname, day, month, year);
>   lcd_write(s);
>

Does lcd_write() remember where it was up to? If so you can break it up:

lcd_write("Hi ");
lcd_write(yourname);
lcd_write(", today is ");

This then only leaves the date, which has a maximum width, eg,
"dd/mm/yyyy". You could also then use a common routine for turning a
date into a string, if it's needed in a few places.

pozz <pozzugno@gmail.com> writes:
>Many times I need to construct a string through a call to sprintf and
>pass it to an external function.
>
> char s[32];
> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
> lcd_write(s);

One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.

I generally always reserve enough space for the largest possible
legal string, particularly when the buffer is on the stack and is
less than a page (4KB) in size.

On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
> pozz <pozz...@gmail.com> writes:
> >Many times I need to construct a string through a call to sprintf and
> >pass it to an external function.
> >
> > char s[32];
> > sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
> > lcd_write(s);
> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
>
It depends whether wrong results are better or worse than no results.

On 17/11/2021 16:36, Malcolm McLean wrote:
> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
>> pozz <pozz...@gmail.com> writes:
>>> Many times I need to construct a string through a call to sprintf and
>>> pass it to an external function.
>>>
>>> char s[32];
>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>> lcd_write(s);
>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
>>
> It depends whether wrong results are better or worse than no results.
>

Generally, a truncated string on the output is better than a stack
overflow with your embedded system crashing or going wild. But your
needs may vary.

On 11/17/2021 12:04 PM, David Brown wrote:
> On 17/11/2021 11:36, pozz wrote:
>> Many times I need to construct a string through a call to sprintf and
>> pass it to an external function.
>>
>>   char s[32];
>>   sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>   lcd_write(s);
>>
>> The size of s is fixed and calculated for the maximum length of
>> yourname, that is 9.
>>
>> Later in time, I need to change the message into:
>>
>>   sprintf(s, "Hello %s, today is %d/%d/%d", yourname, day, month, year);
>>
>> Of course, I need to re-calculate the worst-case length, that should be
>> now 35. However this is error-prone and I could forget to change the
>> size of array.
>>
>> Is there a better way to manage this situation? I can't use malloc()
>> because I'm on an embedded system where I can't use heap.
>>
>> I'm thinking to use sprintf(NULL, ...), such as:
>>
>>   const char fmt[] = "Hi %s, today is %d/%d/%d";
>>   size_t n = sprintf(NULL, fmt, yourname, day, month, year);
>>   char s[n + 1];
>>   sprintf(s, fmt, yourname, day, month, year);
>>   lcd_write(s);
>>
>
> That would work (with your follow-up correction). You might want to put
> a limit on "n" to avoid accidental stack overflow. This arrangement
> does mean that you are doing the printf part twice.
>
> Very often in small systems you know there is a maximum size - if your
> screen is 40 characters wide, then 40 characters is enough in your
> array. And if you might need up to 40 characters then you might as well
> use all of the 40 chars, even though your string might be shorter - you
> really don't want to test your code for the name "Al" on date 1/2/2021
> and then find you have a stack overflow on 10/10/2021 with the name
> "Rhoshandiatellyneshiaunneveshenk". (Apparently that's a real name -
> according to google!)

This sounds like good advice. It makes sense to make use of the
information given by the maximum string length that can actually be emitted.

I'd add the following:
1) use snprintf instead of sprintf; the former is explicitly designed to
handle the buffer size limit.
2) use a better format specifier instead of plain "%s" for the string
argument, e.g. "%2.12s"

Both of the above help preventing buffer overflow, which is something
you need to ensure it never happens.

David Brown <david.brown@hesbynett.no> writes:
>On 17/11/2021 16:36, Malcolm McLean wrote:
>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
>>> pozz <pozz...@gmail.com> writes:
>>>> Many times I need to construct a string through a call to sprintf and
>>>> pass it to an external function.
>>>>
>>>> char s[32];
>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>>> lcd_write(s);
>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
>>>
>> It depends whether wrong results are better or worse than no results.
>>
>
>Generally, a truncated string on the output is better than a stack
>overflow with your embedded system crashing or going wild. But your
>needs may vary.

Indeed. Plus a good programmer checks the return value from snprintf.
Always.

pozz <pozzugno@gmail.com> writes:
> Many times I need to construct a string through a call to sprintf and
> pass it to an external function.
>
> char s[32];
> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
> lcd_write(s);

I presume that lcd_write() doesn't retain the address passed to it, so the
display won't be messed up when the array object s ceases to exist.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

David Brown <david.brown@hesbynett.no> writes:
> On 17/11/2021 16:36, Malcolm McLean wrote:
>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
>>> pozz <pozz...@gmail.com> writes:
>>>> Many times I need to construct a string through a call to sprintf and
>>>> pass it to an external function.
>>>>
>>>> char s[32];
>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>>> lcd_write(s);
>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
>>>
>> It depends whether wrong results are better or worse than no results.
>
> Generally, a truncated string on the output is better than a stack
> overflow with your embedded system crashing or going wild. But your
> needs may vary.

Sure, truncation is probably better than undefined behavior, but
depending on the context it might not be *much* better.

For a small LCD display, truncation is probably the best fallback
(followed by thinking about how to make the message fit). On the other
hand, truncating "rm -rf /home/user/temp_dir" to "rm -rf /home/user" is
likely to be far worse than crashing the program.

There's no general rule other than that you should always *think*
about what will/should happen if there's not enough room in the target
array.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 17/11/2021 18:19, Manfred wrote:
> On 11/17/2021 12:04 PM, David Brown wrote:
>> On 17/11/2021 11:36, pozz wrote:
>>> Many times I need to construct a string through a call to sprintf and
>>> pass it to an external function.
>>>
>>>    char s[32];
>>>    sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>>    lcd_write(s);
>>>
>>> The size of s is fixed and calculated for the maximum length of
>>> yourname, that is 9.
>>>
>>> Later in time, I need to change the message into:
>>>
>>>    sprintf(s, "Hello %s, today is %d/%d/%d", yourname, day, month,
>>> year);
>>>
>>> Of course, I need to re-calculate the worst-case length, that should be
>>> now 35. However this is error-prone and I could forget to change the
>>> size of array.
>>>
>>> Is there a better way to manage this situation? I can't use malloc()
>>> because I'm on an embedded system where I can't use heap.
>>>
>>> I'm thinking to use sprintf(NULL, ...), such as:
>>>
>>>    const char fmt[] = "Hi %s, today is %d/%d/%d";
>>>    size_t n = sprintf(NULL, fmt, yourname, day, month, year);
>>>    char s[n + 1];
>>>    sprintf(s, fmt, yourname, day, month, year);
>>>    lcd_write(s);
>>>
>>
>> That would work (with your follow-up correction).  You might want to put
>> a limit on "n" to avoid accidental stack overflow.  This arrangement
>> does mean that you are doing the printf part twice.
>>
>> Very often in small systems you know there is a maximum size - if your
>> screen is 40 characters wide, then 40 characters is enough in your
>> array.  And if you might need up to 40 characters then you might as well
>> use all of the 40 chars, even though your string might be shorter - you
>> really don't want to test your code for the name "Al" on date 1/2/2021
>> and then find you have a stack overflow on 10/10/2021 with the name
>> "Rhoshandiatellyneshiaunneveshenk".  (Apparently that's a real name -
>> according to google!)
>
> This sounds like good advice. It makes sense to make use of the
> information given by the maximum string length that can actually be
> emitted.
>
> I'd add the following:
> 1) use snprintf instead of sprintf; the former is explicitly designed to
> handle the buffer size limit.

Of course. The OP corrected himself with a follow-up to use snprintf, I
believe.

> 2) use a better format specifier instead of plain "%s" for the string
> argument, e.g. "%2.12s"

That is a possibility, but often %s is fine (with the limit you have
from snprintf).

>
> Both of the above help preventing buffer overflow, which is something
> you need to ensure it never happens.

Indeed.

On 17/11/2021 19:21, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 17/11/2021 16:36, Malcolm McLean wrote:
>>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
>>>> pozz <pozz...@gmail.com> writes:
>>>>> Many times I need to construct a string through a call to sprintf and
>>>>> pass it to an external function.
>>>>>
>>>>> char s[32];
>>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>>>> lcd_write(s);
>>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
>>>>
>>> It depends whether wrong results are better or worse than no results.
>>>
>>
>> Generally, a truncated string on the output is better than a stack
>> overflow with your embedded system crashing or going wild. But your
>> needs may vary.
>
> Indeed. Plus a good programmer checks the return value from snprintf.
> Always.
>

Really? I never do. But I make sure my buffers are the right size for
the job - or that it doesn't matter if there is truncation (such as for
log outputs). I prefer to be sure that my inputs to the function are
correct, than to call the function and check for problems afterwards.
(Different people can have different requirements here - but that's the
way I do it.)

On 17/11/2021 20:22, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 17/11/2021 16:36, Malcolm McLean wrote:
>>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
>>>> pozz <pozz...@gmail.com> writes:
>>>>> Many times I need to construct a string through a call to sprintf and
>>>>> pass it to an external function.
>>>>>
>>>>> char s[32];
>>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>>>> lcd_write(s);
>>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
>>>>
>>> It depends whether wrong results are better or worse than no results.
>>
>> Generally, a truncated string on the output is better than a stack
>> overflow with your embedded system crashing or going wild. But your
>> needs may vary.
>
> Sure, truncation is probably better than undefined behavior, but
> depending on the context it might not be *much* better.
>
> For a small LCD display, truncation is probably the best fallback
> (followed by thinking about how to make the message fit). On the other
> hand, truncating "rm -rf /home/user/temp_dir" to "rm -rf /home/user" is
> likely to be far worse than crashing the program.

Yes - "generally" does not mean "always" ! That's a good example of
when truncation could be rather bad.

>
> There's no general rule other than that you should always *think*
> about what will/should happen if there's not enough room in the target
> array.
>

Alternatively, think about how to ensure that there /always/ will be
enough room in the target array. Either way, always /think/.

David Brown <david.brown@hesbynett.no> writes:
>On 17/11/2021 19:21, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 17/11/2021 16:36, Malcolm McLean wrote:
>>>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
>>>>> pozz <pozz...@gmail.com> writes:
>>>>>> Many times I need to construct a string through a call to sprintf and
>>>>>> pass it to an external function.
>>>>>>
>>>>>> char s[32];
>>>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>>>>> lcd_write(s);
>>>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
>>>>>
>>>> It depends whether wrong results are better or worse than no results.
>>>>
>>>
>>> Generally, a truncated string on the output is better than a stack
>>> overflow with your embedded system crashing or going wild. But your
>>> needs may vary.
>>
>> Indeed. Plus a good programmer checks the return value from snprintf.
>> Always.
>>
>
>Really? I never do. But I make sure my buffers are the right size for
>the job - or that it doesn't matter if there is truncation (such as for
>log outputs). I prefer to be sure that my inputs to the function are
>correct, than to call the function and check for problems afterwards.
>(Different people can have different requirements here - but that's the
>way I do it.)
>

I often use snprintf in place of strcat. For that purpose, checking the return
value is required.

char buffer[1024];
char *bp = buffer;
size_t remaining = sizeof(buffer);
int diag;

diag = snprintf(bp, remaining, "%s", string_to_append_to_buffer);
if (diag != -1 && diag < remaining) {
bp += diag, remaining -= diag;
} else {
/* Handle overflow/error as necessary */
}

....

The only problem is that the return value for snprintf is 'int', while
the buffer size is size_t; which means on systems with a 64-bit size_t,
the return value isn't large enough to express the correct return value
when the size of the result value exceeds 4GB. Not generally a problem in
actual code, but something to be aware of.

David Brown <david.brown@hesbynett.no> writes:
> On 17/11/2021 20:22, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 17/11/2021 16:36, Malcolm McLean wrote:
>>>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
>>>>> pozz <pozz...@gmail.com> writes:
>>>>>> Many times I need to construct a string through a call to sprintf and
>>>>>> pass it to an external function.
>>>>>>
>>>>>> char s[32];
>>>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>>>>> lcd_write(s);
>>>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
>>>>>
>>>> It depends whether wrong results are better or worse than no results.
>>>
>>> Generally, a truncated string on the output is better than a stack
>>> overflow with your embedded system crashing or going wild. But your
>>> needs may vary.
>>
>> Sure, truncation is probably better than undefined behavior, but
>> depending on the context it might not be *much* better.
>>
>> For a small LCD display, truncation is probably the best fallback
>> (followed by thinking about how to make the message fit). On the other
>> hand, truncating "rm -rf /home/user/temp_dir" to "rm -rf /home/user" is
>> likely to be far worse than crashing the program.
>
> Yes - "generally" does not mean "always" ! That's a good example of
> when truncation could be rather bad.

Depending on the context, "generally" can mean either "usually" or
"always". I've found that people generally interpret it in the most
inconvenient way possible.

>> There's no general rule other than that you should always *think*
>> about what will/should happen if there's not enough room in the target
>> array.
>
> Alternatively, think about how to ensure that there /always/ will be
> enough room in the target array. Either way, always /think/.

That's not always possible, especially if the "array" is a display
device. But yes, "always think" is a good idea. I think.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

David Brown <david.brown@hesbynett.no> wrote:
> On 17/11/2021 19:21, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 17/11/2021 16:36, Malcolm McLean wrote:
>>>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
>>>>> pozz <pozz...@gmail.com> writes:
>>>>>> Many times I need to construct a string through a call to sprintf and
>>>>>> pass it to an external function.
>>>>>>
>>>>>> char s[32];
>>>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>>>>> lcd_write(s);
>>>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
>>>>>
>>>> It depends whether wrong results are better or worse than no results.
>>>>
>>>
>>> Generally, a truncated string on the output is better than a stack
>>> overflow with your embedded system crashing or going wild. But your
>>> needs may vary.
>>
>> Indeed. Plus a good programmer checks the return value from snprintf.
>> Always.
>>
>
> Really? I never do. But I make sure my buffers are the right size for
> the job - or that it doesn't matter if there is truncation (such as for
> log outputs). I prefer to be sure that my inputs to the function are
> correct, than to call the function and check for problems afterwards.
> (Different people can have different requirements here - but that's the
> way I do it.)
>

That is generally the best approach, but doesn't work well with snprintf (or
stringification of data types generally), especially in light of the express
concern about robustness to drive-by edits of the format string.

The way to avoid string buffer errors is to avoid strings and stick to
concrete data types or to process data in a rigorously streaming fashion.
That's true of C and other languages--strings aren't data structures,
they're the antithesis of a data structure. But one nonetheless often finds
themselves dealing with strings either on input or output, unfortunately,
and facing the cruel economic calculus of worse is better. Which I suppose
is why every language spends so much effort chasing a better string type
despite the very phrase, string type, being a contradiction in terms.

Il 17/11/2021 12:04, David Brown ha scritto:
> On 17/11/2021 11:36, pozz wrote:
>> Many times I need to construct a string through a call to sprintf and
>> pass it to an external function.
>>
>>   char s[32];
>>   sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>   lcd_write(s);
>>
>> The size of s is fixed and calculated for the maximum length of
>> yourname, that is 9.
>>
>> Later in time, I need to change the message into:
>>
>>   sprintf(s, "Hello %s, today is %d/%d/%d", yourname, day, month, year);
>>
>> Of course, I need to re-calculate the worst-case length, that should be
>> now 35. However this is error-prone and I could forget to change the
>> size of array.
>>
>> Is there a better way to manage this situation? I can't use malloc()
>> because I'm on an embedded system where I can't use heap.
>>
>> I'm thinking to use sprintf(NULL, ...), such as:
>>
>>   const char fmt[] = "Hi %s, today is %d/%d/%d";
>>   size_t n = sprintf(NULL, fmt, yourname, day, month, year);
>>   char s[n + 1];
>>   sprintf(s, fmt, yourname, day, month, year);
>>   lcd_write(s);
>>
>
> That would work (with your follow-up correction). You might want to put
> a limit on "n" to avoid accidental stack overflow. This arrangement
> does mean that you are doing the printf part twice.

I know, this is a drawback.

> Very often in small systems you know there is a maximum size - if your
> screen is 40 characters wide, then 40 characters is enough in your
> array. And if you might need up to 40 characters then you might as well
> use all of the 40 chars, even though your string might be shorter - you
> really don't want to test your code for the name "Al" on date 1/2/2021
> and then find you have a stack overflow on 10/10/2021 with the name
> "Rhoshandiatellyneshiaunneveshenk". (Apparently that's a real name -
> according to google!)

The example was general, because this is a problem I often have: compose
a string now to pass to a function.

For LCD example, if you use a variable-width font, it's difficult to
calc the maximum chars. It depends how many 'i's are in the string.
You could consider the worst case of a string composed by all 'i's...

> It is also worth noting that only one task should be calling lcd_write
> at a time - otherwise your display will be messed up. You can extend
> that and say that only one task will be using the format buffer at a
> time, and then it can be a statically array that is shared by all client
> code.

Il 17/11/2021 20:14, Keith Thompson ha scritto:
> pozz <pozzugno@gmail.com> writes:
>> Many times I need to construct a string through a call to sprintf and
>> pass it to an external function.
>>
>> char s[32];
>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>> lcd_write(s);
>
> I presume that lcd_write() doesn't retain the address passed to it, so the
> display won't be messed up when the array object s ceases to exist.

Yes of course

On 18/11/2021 05:46, William Ahern wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 17/11/2021 19:21, Scott Lurndal wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 17/11/2021 16:36, Malcolm McLean wrote:
>>>>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
>>>>>> pozz <pozz...@gmail.com> writes:
>>>>>>> Many times I need to construct a string through a call to sprintf and
>>>>>>> pass it to an external function.
>>>>>>>
>>>>>>> char s[32];
>>>>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
>>>>>>> lcd_write(s);
>>>>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
>>>>>>
>>>>> It depends whether wrong results are better or worse than no results.
>>>>>
>>>>
>>>> Generally, a truncated string on the output is better than a stack
>>>> overflow with your embedded system crashing or going wild. But your
>>>> needs may vary.
>>>
>>> Indeed. Plus a good programmer checks the return value from snprintf.
>>> Always.
>>>
>>
>> Really? I never do. But I make sure my buffers are the right size for
>> the job - or that it doesn't matter if there is truncation (such as for
>> log outputs). I prefer to be sure that my inputs to the function are
>> correct, than to call the function and check for problems afterwards.
>> (Different people can have different requirements here - but that's the
>> way I do it.)
>>
>
> That is generally the best approach, but doesn't work well with snprintf (or
> stringification of data types generally), especially in light of the express
> concern about robustness to drive-by edits of the format string.
>

It works perfectly well in the type of programming I do. Different
kinds of work have different requirements. In small-systems embedded
programming (which is what I usually work with, and also what the OP is
doing), you know what you are passing to your printf type functions.
You know what the output is connected to (a screen, a UART, a log in
flash, etc.).

But it can be an entirely different matter in other kinds of programming
where you might have the format string coming from an external file of
translations made by a third party, or the endless variety of
complicating factors that can occur on big systems. Scott could be
right that a good programmer always checks the return value of snprintf
when doing the kind of coding he does - but it is not right for the kind
of coding /I/ do.

> The way to avoid string buffer errors is to avoid strings and stick to
> concrete data types or to process data in a rigorously streaming fashion.

The way to avoid string buffer errors is the same as you avoid any other
errors - good development practices. That runs the whole gamut from
high level concerns to low-level details. It includes making sure you
have clear specifications for the code you are writing, making sure the
programmer is appropriately qualified, having code review practices,
testing regimes, automatic checking tools, making sure the data coming
into your code is appropriate, making sure you correctly handle all
cases (including worst cases and pathological cases), and so on. It's
just like any other coding error.

On Thursday, 18 November 2021 at 09:50:36 UTC, David Brown wrote:
> On 18/11/2021 05:46, William Ahern wrote:
> > David Brown <david...@hesbynett.no> wrote:
> >> On 17/11/2021 19:21, Scott Lurndal wrote:
> >>> David Brown <david...@hesbynett.no> writes:
> >>>> On 17/11/2021 16:36, Malcolm McLean wrote:
> >>>>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
> >>>>>> pozz <pozz...@gmail.com> writes:
> >>>>>>> Many times I need to construct a string through a call to sprintf and
> >>>>>>> pass it to an external function.
> >>>>>>>
> >>>>>>> char s[32];
> >>>>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
> >>>>>>> lcd_write(s);
> >>>>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
> >>>>>>
> >>>>> It depends whether wrong results are better or worse than no results.
> >>>>>
> >>>>
> >>>> Generally, a truncated string on the output is better than a stack
> >>>> overflow with your embedded system crashing or going wild. But your
> >>>> needs may vary.
> >>>
> >>> Indeed. Plus a good programmer checks the return value from snprintf.
> >>> Always.
> >>>
> >>
> >> Really? I never do. But I make sure my buffers are the right size for
> >> the job - or that it doesn't matter if there is truncation (such as for
> >> log outputs). I prefer to be sure that my inputs to the function are
> >> correct, than to call the function and check for problems afterwards.
> >> (Different people can have different requirements here - but that's the
> >> way I do it.)
> >>
> >
> > That is generally the best approach, but doesn't work well with snprintf (or
> > stringification of data types generally), especially in light of the express
> > concern about robustness to drive-by edits of the format string.
> >
> It works perfectly well in the type of programming I do. Different
> kinds of work have different requirements. In small-systems embedded
> programming (which is what I usually work with, and also what the OP is
> doing), you know what you are passing to your printf type functions.
> You know what the output is connected to (a screen, a UART, a log in
> flash, etc.).
>
> But it can be an entirely different matter in other kinds of programming
> where you might have the format string coming from an external file of
> translations made by a third party, or the endless variety of
> complicating factors that can occur on big systems. Scott could be
> right that a good programmer always checks the return value of snprintf
> when doing the kind of coding he does - but it is not right for the kind
> of coding /I/ do.
>
I tend to use C++ for strings because C++ strings are assignable, destructible,
returnable, and C++ manages the buffer. C isn't a good language for doing
string processing in (though it is a good language for implementing string
processing algorithms themselves in).
>
> > The way to avoid string buffer errors is to avoid strings and stick to
> > concrete data types or to process data in a rigorously streaming fashion.
> The way to avoid string buffer errors is the same as you avoid any other
> errors - good development practices. That runs the whole gamut from
> high level concerns to low-level details. It includes making sure you
> have clear specifications for the code you are writing, making sure the
> programmer is appropriately qualified, having code review practices,
> testing regimes, automatic checking tools, making sure the data coming
> into your code is appropriate, making sure you correctly handle all
> cases (including worst cases and pathological cases), and so on. It's
> just like any other coding error.
>
This all costs money, it demands management skills and resources
the company may not have, and it can lead to programmers feeling
over-managed.
A very important factor is the testability of the code, and the consequences
of an error. You can over-engineer processes as well as actual code.

On Thursday, November 18, 2021 at 8:57:04 AM UTC-3, Malcolm McLean wrote:
> On Thursday, 18 November 2021 at 09:50:36 UTC, David Brown wrote:
> > On 18/11/2021 05:46, William Ahern wrote:
> > > David Brown <david...@hesbynett.no> wrote:
> > >> On 17/11/2021 19:21, Scott Lurndal wrote:
> > >>> David Brown <david...@hesbynett.no> writes:
> > >>>> On 17/11/2021 16:36, Malcolm McLean wrote:
> > >>>>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
> > >>>>>> pozz <pozz...@gmail.com> writes:
> > >>>>>>> Many times I need to construct a string through a call to sprintf and
> > >>>>>>> pass it to an external function.
> > >>>>>>>
> > >>>>>>> char s[32];
> > >>>>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
> > >>>>>>> lcd_write(s);
> > >>>>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
> > >>>>>>
> > >>>>> It depends whether wrong results are better or worse than no results.
> > >>>>>
> > >>>>
> > >>>> Generally, a truncated string on the output is better than a stack
> > >>>> overflow with your embedded system crashing or going wild. But your
> > >>>> needs may vary.
> > >>>
> > >>> Indeed. Plus a good programmer checks the return value from snprintf.
> > >>> Always.
> > >>>
> > >>
> > >> Really? I never do. But I make sure my buffers are the right size for
> > >> the job - or that it doesn't matter if there is truncation (such as for
> > >> log outputs). I prefer to be sure that my inputs to the function are
> > >> correct, than to call the function and check for problems afterwards.
> > >> (Different people can have different requirements here - but that's the
> > >> way I do it.)
> > >>
> > >
> > > That is generally the best approach, but doesn't work well with snprintf (or
> > > stringification of data types generally), especially in light of the express
> > > concern about robustness to drive-by edits of the format string.
> > >
> > It works perfectly well in the type of programming I do. Different
> > kinds of work have different requirements. In small-systems embedded
> > programming (which is what I usually work with, and also what the OP is
> > doing), you know what you are passing to your printf type functions.
> > You know what the output is connected to (a screen, a UART, a log in
> > flash, etc.).
> >
> > But it can be an entirely different matter in other kinds of programming
> > where you might have the format string coming from an external file of
> > translations made by a third party, or the endless variety of
> > complicating factors that can occur on big systems. Scott could be
> > right that a good programmer always checks the return value of snprintf
> > when doing the kind of coding he does - but it is not right for the kind
> > of coding /I/ do.
> >
> I tend to use C++ for strings because C++ strings are assignable, destructible,
> returnable, and C++ manages the buffer. C isn't a good language for doing
> string processing in (though it is a good language for implementing string
> processing algorithms themselves in).

I moved from C++ to C and I don't miss std::string. Quite the opposite, I don't feel
comfortable using std::string/std::wstring anymore even in C++.

One problem of std::string tries to do two different jobs at the same time
using the same object. One job is "string builder" and a the other "string holder"

Using std::string as string holder is a waste of memory. For instance:
std::map<std::string, something>
Map doesn't want build string, it just need to hold a string.

Another bad thing about std::string is to have to use .c_str() to make
it compatible with C strings. Clearly std::string is not a built-in
language string. "literals" are not std::string.

void F1(std::string s);
void F2(const std::string& s);
F("this is very bad because heap is used");
F("this is also very bad heap is used");

I have being using std::wstring for a long time. When moving to C
everything in my code is char* and it means UTF8. Life is so much
easier with much less conversions. It is amazing how few function we
need to work with UTF8. The same existing function can be used.
For instance, strcat is fine, strlen (if you need byte len), strdup etc.. everything just works.
u8"utf encoded" also completes the task.

What is missing. Because I create windows programs I miss the open_memstream.
This is for the job of "build strings" and to use the same FILE* functions.

So in C:
const char * or char * to represent and hold strings.
snprintf and open_memstream to build (and format) strings.

Dangerous parts...

strncpy because may not add NULL. ( I have heart of strlcpy )

replacement .
object->text = strdup("new text"); //this may cause a leak

especially for this replacement problem I think C++ has an advantage.

Something I use this that free the previous string.
replace_string(&object->text, strdup("new text"));

Am 17.11.21 um 14:11 schrieb Thiago Adams:
>
> See : asprintf
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1248.pdf

asprintf allocates on the heap "as if by malloc", so if he can't use
malloc, he can't use asprintf.