433029 - dosprintf functions return different results than sysmet sprintf for %lu on 64 bit platforms

Status: RESOLVED INVALID

(NSPR :: NSPR, defect)

Description

[Simo Sorce]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080416 Fedora/2.0.0.14-1.fc8 Firefox/2.0.0.14 pango-text
Build Identifier: 

I used the following snippet on a 64 bit machine to test if slapi_ch_smprintf (use d in fedora directory sever) that uses PR_vmsprintf which uses dosprintf to test that the NSPR implementation returns different values from the system printf familiy of funtions:

#include <stdio.h>
#include "slapi-plugin.h"
int main(int argc, char *argv[]) {
   char *test; 
   char *test2; 
   unsigned long maxval = -1;
   test = slapi_ch_smprintf("%u, %lu, %llu", maxval, maxval, maxval); 
   asprintf(&test2, "%u, %lu, %llu", maxval, maxval, maxval); 
   fprintf(stdout, "%s\n", test);
   fprintf(stdout, "%s\n", test2);
}

on my system I get this output:

$ ./print 
4294967295, 4294967295, 18446744073709551615
4294967295, 18446744073709551615, 18446744073709551615

As you can see on 64 bit arches NSPR treat %lu as a 32 bit unsigned integre while system libraries treat it as 64 bit unsigned.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
implementaion differ from system one

Expected Results:  
implementation behaves the same

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

This is working as intended and as documented.
The NSPR header file that declares NSPR's printf-style functions, "prprf.h"
defines %u, %lu, %llu as follows:

  **  %hd, %hu, %hx, %hX, %ho - 16-bit versions of above
  **  %ld, %lu, %lx, %lX, %lo - 32-bit versions of above
  **  %lld, %llu, %llx, %llX, %llo - 64 bit versions of above

This is so that NSPR's printf formats will match NSPR's types, e.g.
%h  for PRInt16
%l  for PRInt32
%ll for PRInt64

The online documentation for these functions at 
  http://www.mozilla.org/projects/nspr/reference/html/prprf.html#23299
says:

 * An h if the integer is to be printed as a 16 bit value, a l if 32 bits, 
   or ll if 64 bits. 

Comment 2

[Wan-Teh Chang]

Right.  The issue is whether slapi_ch_smprintf is supposed
to interpret %ld as a 'long int' or 'int32'.  If
slapi_ch_smprintf has a backward compatibility requirement,
I'm afraid that you have no choice but to document the
current behavior.

Comment 3

[Simo Sorce]

Oh, sorry didn't see NSPR already documented this.
I guess we just need to open a doc bug against slapi_ch_smprintf then, thanks for the quick answer.