say yo may this case - its a printf like wrapper who just renders text
on screen bitmap (though i could use it to render also on some ram
bitmaps - so the length of text used here is limited to size of bitmap,
say i rarelu use bitmaps larger than say 8k and rarely fonts
smaller than 10 pixel wide so the 8k/10 = 800 length at most) -
i know its under those mentioned assumptions okbut how to do it
properly?
ÿstatic BMFont* tahomaÿ = NULL;
ÿint tahoma_sizeÿ = 23;
ÿvoid text_xy_colors_tahoma(int x, int y, unsigned* colors, char*
format, ...)
ÿ{
ÿÿ if(!tahoma)ÿ tahomaÿ = AllocFont("Tahoma", tahoma_size, 500);
ÿÿ static char text[1000];
ÿÿ va_list args;
ÿÿ va_start(args, format);
ÿÿ vsprintf(text, format, args);
ÿÿ va_end(args);
ÿÿ DrawText_BM_colors(tahoma, x,y,ÿ text, colors);
ÿ}
On 11/09/2026 14:28, fir wrote:
say yo may this case - its a printf like wrapper who just renders text
on screen bitmap (though i could use it to render also on some ram
bitmaps - so the length of text used here is limited to size of bitmap,
say i rarelu use bitmaps larger than say 8k and rarely fonts
smaller than 10 pixel wide so the 8k/10 = 800 length at most) -
i know its under those mentioned assumptions okbut how to do it
properly?
ÿÿstatic BMFont* tahomaÿ = NULL;
ÿÿint tahoma_sizeÿ = 23;
ÿÿvoid text_xy_colors_tahoma(int x, int y, unsigned* colors, char*
format, ...)
ÿÿ{
ÿÿÿ if(!tahoma)ÿ tahomaÿ = AllocFont("Tahoma", tahoma_size, 500);
ÿÿÿ static char text[1000];
ÿÿÿ va_list args;
ÿÿÿ va_start(args, format);
ÿÿÿ vsprintf(text, format, args);
ÿÿÿ va_end(args);
ÿÿÿ DrawText_BM_colors(tahoma, x,y,ÿ text, colors);
ÿÿ}
IMHO, it is fine to have a fixed buffer size like this.ÿ But you really should use "vsnprintf(text, sizeof(text), format, args);".ÿ Then if your code accidentally uses too long a message, it gets truncated instead of stomping over random memory space.
Also note that with a "static" buffer, you'll get a mess (and UB) if you call the function from two threads at the same time.ÿ That may or may
not matter to you.
David Brown pisze:
On 11/09/2026 14:28, fir wrote:
say yo may this case - its a printf like wrapper who just renders
text on screen bitmap (though i could use it to render also on some
ram bitmaps - so the length of text used here is limited to size of
bitmap,
say i rarelu use bitmaps larger than say 8k and rarely fonts
smaller than 10 pixel wide so the 8k/10 = 800 length at most) -
i know its under those mentioned assumptions okbut how to do it
properly?
ÿÿstatic BMFont* tahomaÿ = NULL;
ÿÿint tahoma_sizeÿ = 23;
ÿÿvoid text_xy_colors_tahoma(int x, int y, unsigned* colors, char*
format, ...)
ÿÿ{
ÿÿÿ if(!tahoma)ÿ tahomaÿ = AllocFont("Tahoma", tahoma_size, 500);
ÿÿÿ static char text[1000];
ÿÿÿ va_list args;
ÿÿÿ va_start(args, format);
ÿÿÿ vsprintf(text, format, args);
ÿÿÿ va_end(args);
ÿÿÿ DrawText_BM_colors(tahoma, x,y,ÿ text, colors);
ÿÿ}
IMHO, it is fine to have a fixed buffer size like this.ÿ But you
really should use "vsnprintf(text, sizeof(text), format, args);".
Then if your code accidentally uses too long a message, it gets
truncated instead of stomping over random memory space.
ye you right here, im not used to vsprintf yet and i sometimes
prototyping codes (some could say - prototyping codes is normal
(by prototyping i mean writing it in not optimal state taking edge cases
and so on just to move faster)
Also note that with a "static" buffer, you'll get a mess (and UB) if
you call the function from two threads at the same time.ÿ That may or
may not matter to you.
thsi ttotally no problem i write 1 core
as to this static buffer it has his barbaric style but im not sure its strictly proper..probably stack (VLA) based solution would be more
proper but there is a problem
sometimes i code c in c++ compiler mode (i dont care co even check as
its close and i compile sometimes c mode sometimes c++) and its said c++
not support VLA - this is also bad becouse the best would be the subset
od c/c++ to compile in both
i distaste c++ much though i began to think if to even use references as
c should have references in fact, allows codes be shorter
fir pisze:
David Brown pisze:
On 11/09/2026 14:28, fir wrote:
say yo may this case - its a printf like wrapper who just renders
text on screen bitmap (though i could use it to render also on some
ram bitmaps - so the length of text used here is limited to size of
bitmap,
say i rarelu use bitmaps larger than say 8k and rarely fonts
smaller than 10 pixel wide so the 8k/10 = 800 length at most) -
i know its under those mentioned assumptions okbut how to do it
properly?
ÿÿstatic BMFont* tahomaÿ = NULL;
ÿÿint tahoma_sizeÿ = 23;
ÿÿvoid text_xy_colors_tahoma(int x, int y, unsigned* colors, char*
format, ...)
ÿÿ{
ÿÿÿ if(!tahoma)ÿ tahomaÿ = AllocFont("Tahoma", tahoma_size, 500);
ÿÿÿ static char text[1000];
ÿÿÿ va_list args;
ÿÿÿ va_start(args, format);
ÿÿÿ vsprintf(text, format, args);
ÿÿÿ va_end(args);
ÿÿÿ DrawText_BM_colors(tahoma, x,y,ÿ text, colors);
ÿÿ}
IMHO, it is fine to have a fixed buffer size like this.ÿ But you
really should use "vsnprintf(text, sizeof(text), format, args);".
Then if your code accidentally uses too long a message, it gets
truncated instead of stomping over random memory space.
ye you right here, im not used to vsprintf yet and i sometimes
prototyping codes (some could say - prototyping codes is normal
(by prototyping i mean writing it in not optimal state taking edge
cases and so on just to move faster)
Also note that with a "static" buffer, you'll get a mess (and UB) if
you call the function from two threads at the same time.ÿ That may or
may not matter to you.
thsi ttotally no problem i write 1 core
as to this static buffer it has his barbaric style but im not sure its
strictly proper..probably stack (VLA) based solution would be more
proper but there is a problem
sometimes i code c in c++ compiler mode (i dont care co even check as
its close and i compile sometimes c mode sometimes c++) and its said
c++ not support VLA - this is also bad becouse the best would be the
subset
od c/c++ to compile in both
i distaste c++ much though i began to think if to even use references as
c should have references in fact, allows codes be shorter
as to this VLA's it seems that there should be some mechanism that allow
to client function to use it as its kinda infinite
char vtab[0];
vla_vsprintf(vtab, format, args);
the client codeÿ vould need probbaly to call some function or use
keyword like
vla_set_size(vtab, 200); something like that..
it is not present as far as i know
im not proably a fan as i once saidÿ that normal callstack be holding
local variables probably there should be few separate stacks
im not sure hevever how many separate like callstack should only hold retvalues where im not sure if srhuments, static size locals, and
thise vlas should have 3 separate or 2 or 1
in morern times i would say im not a fan of ststic buffer ofsuch type as in this code i would consider even malloc
such type as in this code i would consider even malloc
in morern times i would say im not a fan of ststic buffer of
char* text = (char*)malloc(10000);
free(text);
probably better but i would afraid that it has notable overhead some
and such calls of this kind of functions could be often maybe
so maybe thinkig of it its better to have one pice of trash ram for all
such temporary usage?
char temp_ram[10*1024*1024];
void text_xy_colors_tahoma(int x, int y, unsigned* colors, char*
ÿformat, ...)
ÿÿ {
ÿÿÿÿ if(!tahoma)ÿ tahomaÿ = AllocFont("Tahoma", tahoma_size, 500);
ÿÿÿ va_list args;
ÿÿÿÿ va_start(args, format);
ÿÿÿÿ vsprintf(temp_ram, format, args);
ÿÿÿÿ va_end(args);
ÿÿÿÿ DrawText_BM_colors(tahoma, x,y,ÿ temp_ram, colors);
ÿÿ }
im close to starting using this..in a way this makes codes simpler
(les names less instances)
fir pisze:
such type as in this code i would consider even malloc
in morern times i would say im not a fan of ststic buffer of
char* text = (char*)malloc(10000);
free(text);
probably better but i would afraid that it has notable overhead some
and such calls of this kind of functions could be often maybe
so maybe thinkig of it its better to have one pice of trash ram for
all such temporary usage?
char temp_ram[10*1024*1024];
void text_xy_colors_tahoma(int x, int y, unsigned* colors, char*
ÿÿformat, ...)
ÿÿÿ {
ÿÿÿÿÿ if(!tahoma)ÿ tahomaÿ = AllocFont("Tahoma", tahoma_size, 500);
ÿÿÿÿ va_list args;
ÿÿÿÿÿ va_start(args, format);
ÿÿÿÿÿ vsprintf(temp_ram, format, args);
ÿÿÿÿÿ va_end(args);
ÿÿÿÿÿ DrawText_BM_colors(tahoma, x,y,ÿ temp_ram, colors);
ÿÿÿ }
im close to starting using this..in a way this makes codes simpler
(les names less instances)
i will probbaly try it (maybe i use some other name like temp_buffer
maybe better some shorter but unique?)
i think koncet of usinh it when using widelly could be quite more
usefull, becouse api calls could communicate thru this and it make
avoiding some names typing
this in back times could be considered bad design but when using with a
head maybe it could be good..at least its better than local static buffers
IMHO, it is fine to have a fixed buffer size like this. But you[...]
really should use "vsnprintf(text, sizeof(text), format, args);".
Then if your code accidentally uses too long a message, it gets
truncated instead of stomping over random memory space.
David Brown <david.brown@hesbynett.no> writes:
[...]
IMHO, it is fine to have a fixed buffer size like this. But you[...]
really should use "vsnprintf(text, sizeof(text), format, args);".
Then if your code accidentally uses too long a message, it gets
truncated instead of stomping over random memory space.
Think carefully about what will happen if the string is truncated.
If you're writing a human-readable log, for example, quietly
truncating the string might be acceptable, though it might also be
good to have an indication that the data was truncated (perhaps by
appending "..." or "?" to the truncated message).
If the potentially truncated string is going to be executed
as a command, quiet truncation can be deadly. Consider what
happens if you quietly truncate "rm -rf /home/username/tmpdir" to
"rm -rf /home/username".
Fortunately vsnprintf and related functions let you detect this.
The return value is the number of characters that would have been
if enough space had been available. If that's greater than or
equal to the value you passed as the size argument, it was truncated.
But it's (too) easy to forget to check.
Some implementations provide non-standard asprintf() and vasprintf() functions that write to an allocated string.
On 11/09/2026 20:03, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
[...]
IMHO, it is fine to have a fixed buffer size like this. But you[...]
really should use "vsnprintf(text, sizeof(text), format, args);".
Then if your code accidentally uses too long a message, it gets
truncated instead of stomping over random memory space.
Think carefully about what will happen if the string is truncated.
If you're writing a human-readable log, for example, quietly
truncating the string might be acceptable, though it might also be
good to have an indication that the data was truncated (perhaps by
appending "..." or "?" to the truncated message).
If the potentially truncated string is going to be executed
as a command, quiet truncation can be deadly. Consider what
happens if you quietly truncate "rm -rf /home/username/tmpdir" to
"rm -rf /home/username".
Fortunately vsnprintf and related functions let you detect this.
The return value is the number of characters that would have been
if enough space had been available. If that's greater than or
equal to the value you passed as the size argument, it was truncated.
But it's (too) easy to forget to check.
Some implementations provide non-standard asprintf() and vasprintf()
functions that write to an allocated string.
My common use-case (and I use this kind of thing a lot) is for debug log >messages that only developers and testers will ever see, so truncation
is fine for that purpose. But you make good points for other possible >use-cases - truncation is not necessarily a harmless operation!
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 8 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 14:41:52 |
| Calls: | 220 |
| Files: | 21,513 |
| Messages: | 83,058 |