User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/2008071615 Fedora/3.0.1-1.fc9 Firefox/3.0.1 Build Identifier: I have some code that is using the inttypes.h macros for print formatting with calls to PR_vsnprintf(). On a x86_64 system, building and running the attached test program code will show that PR_snprintf interprets PRIu64 (defined as lu) as a 32-bit integer, regardless of the wordsize of the system. The offending code seems to be in the dosprintf() function in NSPR here: http://mxr.mozilla.org/nspr/source/nsprpub/pr/src/io/prprf.c#807 It seems like the proper thing to do is to set "type" to "TYPE_INT64" when we encounter the first "l" on a system where LP64 is defined (or checking that the underying system long is 64-bit by some other means). Reproducible: Always
Created attachment 342936 [details] Test Program Code This test program code will demonstrate the bug when compiled and executed.
Summary: PR_snprintf() does not deal with %llu properly on LP64 systems → PR_snprintf() does not deal with %lu properly on LP64 systems
Although the subject of this bug says the problem is with %llu, comment 0 seems to be complaining about %lu. In the rest of this comment, I will assume that the complaint is actually about %lu. The complaint is that %ls is interpreted as a 32-bit value, even on code compiled with an LP64 model. Please confirm that that is the actual complaint. Assuming that is the actual complaint, then the answer is: it is worked as intended and as specified, and this bug is invalid. The format specifiers implemented by NSPR's printf-style functions do not have the same definition as the ANSI c definitions. It is not a bug that NSPR's format specifiers are different from ANSI's. That is intentional, by design. NSPR's format specifiers have sizes that are not platform dependent. NSPR defines typedefs whose sizes are not platform dependent (e.g. PRUint32, PRUint64) and NSPR's format specifiers are designed to work with those NSPR types. NSPR has no format specifier that corresponds exactly to c's "long" on every platform. Please read the definition of NSPR's format specifiers in http://mxr.mozilla.org/security/source/nsprpub/pr/include/prprf.h#42 Then, if you believe your usage is consistant with that definition, add more comments to this bug explaining that. Otherwise, please confirm that the problem here is that your usage was not consistent with NSPR's definition.
I see that you've already modified the bug subject, confirming that the problem was that you expected %lu to be a 64-bit type on LP64 systems.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.