Last Comment Bug 360169 - Binary incompatibility with PR_GetSystemInfo
: Binary incompatibility with PR_GetSystemInfo
Product: NSPR
Classification: Components
Component: NSPR (show other bugs)
: 4.6.2
: P1 major (vote)
: 4.6.4
Assigned To: Wan-Teh Chang
: Wan-Teh Chang
Depends on: 312199
  Show dependency treegraph
Reported: 2006-11-09 12:12 PST by Nelson Bolyard (seldom reads bugmail)
Modified: 2006-11-13 17:12 PST (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Proposed patch (666 bytes, patch)
2006-11-13 16:09 PST, Wan-Teh Chang
christophe.ravel.bugs: review+
nelson: review+
Details | Diff | Splinter Review

Description Nelson Bolyard (seldom reads bugmail) 2006-11-09 12:12:12 PST
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
Comment 1 Wan-Teh Chang 2006-11-09 18:09:00 PST
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?
Comment 2 Nelson Bolyard (seldom reads bugmail) 2006-11-13 15:53:21 PST
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.
Comment 3 Nelson Bolyard (seldom reads bugmail) 2006-11-13 15:55:32 PST
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.
Comment 4 Wan-Teh Chang 2006-11-13 16:09:45 PST
Created attachment 245508 [details] [diff] [review]
Proposed patch
Comment 5 Nelson Bolyard (seldom reads bugmail) 2006-11-13 16:30:54 PST
Comment on attachment 245508 [details] [diff] [review]
Proposed patch

Comment 6 Wan-Teh Chang 2006-11-13 16:53:33 PST
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

Checking in _hpux.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_hpux.h,v  <--  _hpux.h
new revision:; previous revision:

Note You need to log in before you can comment on or make changes to this bug.