We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4275 - SDL_vsnprintf() updates for zero-padding
Summary: SDL_vsnprintf() updates for zero-padding
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: HG 2.0
Hardware: All All
: P2 normal
Assignee: Ozkan Sezer
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-26 19:30 UTC by Ozkan Sezer
Modified: 2018-09-27 06:38 UTC (History)
0 users

See Also:

Attachments
pad_zeroes.patch for SDL_vsnprintf() (2.94 KB, patch)
2018-09-26 19:30 UTC, Ozkan Sezer 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ozkan Sezer 2018-09-26 19:30:27 UTC 
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?
Comment 1 Sam Lantinga 2018-09-26 21:04:58 UTC 
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.
Comment 2 Ozkan Sezer 2018-09-26 21:29:06 UTC 
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?
Comment 3 Ozkan Sezer 2018-09-27 06:07:07 UTC 
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?
Comment 4 Sam Lantinga 2018-09-27 06:20:42 UTC 
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!
Comment 5 Ozkan Sezer 2018-09-27 06:38:18 UTC 
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.