The NSPR manifest, at mozilla/nsprpub/pr/include/MANIFEST, exports private and obsolete files. Some of the types in these files conflict with those in prtypes.h, which is bad. obsolete/protypes.h obsolete/prsem.h obsolete/probslet.h private/prpriv.h private/pprio.h private/pprthred.h

These obsolete and private headers are intentionally exported. These three private headers should really be called "friend". They can be included under special circumstances. The obsolete headers must be exported until it is okay for us to break backward compatibility (NSPR 4.0). What types in these files conflict with those in prtypes.h?

Changed target milestone to M6.

The xpidl project is picking up uint64 & friends from obsolete/protypes.h instead of prtypes.h. There may be other examples. Recall that we can't control the order in which the build tools find header files when scanning include paths.

uint64 and friends are defined in obsolete/protypes.h, not prtypes.h. The types defined in prtypes.h are PRUint64 and friends, with the PR prefix. uint64 and friends are also defined in the system header files on some operating systems. Maybe this is what's happening? You can see all the ugly workarounds we have in obsolete/protypes.h.

Uh, OK. I was confused. libxpt was using those uint64 types, instead of PR types, and seeing them resolved via an obsolete header scared me.

If libxpt is new code written by Netscape or mozilla.org developers, it should not use the obsolete uint64 types. Our own new code should use the PR types. Some time we need to go through our old code and convert all the obsolete uint64 types to the PR types.

Marked the bug resolved-invalid. The three obsolete and three private headers that Simon Fraser listed need to be exported. New code should not use the obsolete headers, and old code should be rewritten to not use the obsolete headers. The three private headers may be included under special circumstances, i.e., their privateness is comparable to C++'s "friend" classes and functions. Be sure to check with the NSPR group before using any of those three private headers. NSPR also has some truly private headers (private/primpl.h and md/*.h) that are not exported and should never be included.

sounds good to me.

If we need to rewrite old code to stop using the obsolete headers, then we should leave this bug open as a placeholder until we can investigate and identify the code that needs to be rewritten. Then we can write up bugs for that code, rewrite it, stop exporting the headers, and close all the bugs.

Gordon, that would be a separate bug with the description "Remove use of obsolete NSPR types and functions in SeaMonkey". That task is not Mac-specific.

Great! When you submit that bug, put me on the cc list. Then I'll close this one. I thought only the Mac was exporting these files, because the Mac is the only one using the MANIFEST file.

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.

Clearing resolution.

phillip gone, removing him from qa contact, sorry for spam

Okay, these files aren't going away anytime soon, and it doesn't look like they really need to. Marking bug resolved - invalid, as wtc did originally.