PR_snprintf() does not deal with %lu properly on LP64 systems



10 years ago
10 years ago


(Reporter: nkinder, Assigned: Wan-Teh Chang)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 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:

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

Comment 1

10 years ago
Created attachment 342936 [details]
Test Program Code

This test program code will demonstrate the bug when compiled and executed.


10 years ago
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 

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
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.
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.