Open Bug 1197205 Opened 5 years ago Updated 3 years ago

get rid of PR_s{,n}printf et al calls

Categories

(Core :: General, defect)

defect
Not set
normal

Tracking

()

People

(Reporter: froydnj, Unassigned)

References

Details

(Keywords: meta)

PR_s{,n}printf has a couple of issues:

- It doesn't accept the same set of formatting characters as the standard s{,n}printf does.
- Some of the formatting characters it does accept mean different things than the standard ones do (e.g. %ld means "32-bit int", not "long int").
- It doesn't support format string checking on compilers that support that (GCC and I think clang).

We'd like to reduce our dependence on NSPR, so this is a good place to start.  Just using s{,n}printf is fairly straightforward; we do have to use the mozilla/Snprintf.h polyfill until we move to MSVC 2015, though.

The only tricky cases are printing pointers (%p) and floats (%f, %g).  Ideally the only time we print either of those with PR_s{,n}printf are in log files or debug mode messages, so web content or internal tests won't depend on the exact formatting.

Let's use this as a meta-bug for splitting up the work amongst directories.
Depends on: 1197306
Depends on: 1197307
Depends on: 1197309
Depends on: 1197311
Depends on: 1197313
Depends on: 1197314
Depends on: 1197315
Depends on: 1197316
Depends on: 1197328
Depends on: 1197331
Depends on: 1302163
After bug 1060419, most calls to PR_snprintf are in security/nss and nspr itself.
However there are still a few probably-dubious uses in libstagefright, of the form

#if _MSC_VER < 1900
#include <nspr/prprf.h>
#define snprintf PR_snprintf
#endif
You need to log in before you can comment on or make changes to this bug.