The function PR_GetSystemInfo(PR_SI_*,...) doesn't return the same string in NSPR 4.6 as it does in NSPR 4.5.2. Programs built against NSPR 4.5.2, that test the string returned by that function, fail when run with NSPR 4.6. In npsr 4.5.2, it used to return: HP-UX B.11.11 hppa In nspr 4.6, it now returns: HP-UX B.11.11 hppa1.1
The returned strings are the other way around. The bug description should read: In npsr 4.5.2, it used to return: HP-UX B.11.11 hppa1.1 In nspr 4.6, it now returns: HP-UX B.11.11 hppa The string comes from the _PR_SI_ARCHITECTURE macro, which is defined in mozilla/nsprpub/pr/include/md/_hpux.h. The macro has the value "hppa1.1" in NSPR 4.5.2. Since the PA-RISC processor architecture has at least version 1.1 and version 2.0, I thought it's a bug to return "hppa1.1" for all PA-RISC processors, so I removed the version "1.1" from the _PR_SI_ARCHITECTURE macro. Do you want me to change it back to the hard-coded "hppa1.1" or do you want me to return "hppa1.1" on PA-RISC 1.1 processors and "hppa2.0" on PA-RISC 2.0 processors?
Wan-Teh, it seems that this is a case where we must be "bug compatible". The string output by PR_GetSystemInfo must be the same as before, even if that string was (and will again be) in error on PARisc 2.0 machines.
This is Sun CR 6491238. Hopefully we can release the fix together with NSS 3.11.4 I'm guessing at the NSPR target milestone here. Feel free to correct.
Created attachment 245508 [details] [diff] [review] Proposed patch
Comment on attachment 245508 [details] [diff] [review] Proposed patch r=nelson
I checked in the proposed patch on the NSPR trunk (NSPR 4.7) and the NSPR_4_6_BRANCH (NSPR 4.6.4). Checking in _hpux.h; /cvsroot/mozilla/nsprpub/pr/include/md/_hpux.h,v <-- _hpux.h new revision: 3.21; previous revision: 3.20 done Checking in _hpux.h; /cvsroot/mozilla/nsprpub/pr/include/md/_hpux.h,v <-- _hpux.h new revision: 220.127.116.11; previous revision: 18.104.22.168 done