| Summary: | SDL_vsnprintf() updates for zero-padding | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Ozkan Sezer <sezeroz> |
| Component: | *don't know* | Assignee: | Ozkan Sezer <sezeroz> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | HG 2.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | pad_zeroes.patch for SDL_vsnprintf() | ||
We shouldn't have any SDL specific behavior here. I'm guessing that matched whatever C runtime I was comparing against at the time, probably Windows msvcrt. If neither glibc nor msvcrt have zero padding, we should pull that. I don't know about msvcrt, but glibc doesn't zero-pad. E.g.: {SDL_}snprintf(buf,sizeof(buf),"0x%10.*x",6,foo_int) prints
this:
0x 00007b [GLIBC]
0x000000007b [SDL20]
And I like SDL's version better. The only issue is we
shouldn't unconditionally zero-pad for plain %u.
What do I do?
I just built (mingw, against msvcrt.dll) and ran the following:
#include <stdio.h>
char buf[64];
int foo_int = 123;
int main (void) {
_snprintf(buf,sizeof(buf),"0x%10.*x",6,foo_int);
printf("%s\n",buf);
return 0;
}
... and it prints "0x 00007b", i.e. msvcrt.dll does not
unconditionally zero-pad, either.
Shall I push my patch with the unconditional zero-padding
removed?
Yes please. The SDL version looks better, but the functions are supposed to be drop-in replacements for stdlib functions, so we should have the same behavior. Thanks! Pushed https://hg.libsdl.org/SDL/rev/08b190d518fc . Closing. There still might be issues with return value when dest has not enough space, but that should be a story for a later time. |
Created attachment 3317 [details] pad_zeroes.patch for SDL_vsnprintf() The attached patch does the following, please review: - force-enable pad_zeroes for %u (which seems like an SDL-specific behavior) _only_ if radix is not 10. otherwise ignore pad_zeroes, like glibc. - ignore pad_zeroes for %d and %i if a precision is given. - ignore pad_zeroes for %s and %S. OK to apply?