362488 - Proposal: Add definitions to NSPR for the range of error codes reserved for NSS

Status: RESOLVED WONTFIX

(NSPR :: NSPR, defect)

Description

[Kai Engert (:KaiE:)]

The problem I'm trying to solve:

- make the core of the Mozilla clients aware of the existence of NSS error codes
- do not make the core of Mozilla dependent on NSS header files, because the crypto code is fully external and modular

In the core of the Mozilla clients error handling, I'm trying to determine, whether an error code belongs to NSS. Only if the decision is positive, I want to call into PSM and ask for detailed error message.

Currently, the Mozilla client's networking code uses a function, that maps NSPR error codes to higher level application error codes.

I want to extend that function, and introduce an application code that means "failure at NSS level".

I could do so with the following code:

+        if ((errorCode >= (-0x2000) && errorCode < ((-0x2000) + 1000))
+            || (errorCode >= (-0x3000) && errorCode < ((-0x3000) + 1000))) {
+            rv = NS_ERROR_NSS_FAILURE;

But I think hardcoding the numbers is ugly.
I'd prefer to have a macro for that, or at least defines for the numbers.

In NSPR file prerr.h, could we include the range of error numbers reserved for NSS?

It seems reasonable to me to do that, because we have to guarantee that NSPR and NSS coexist nicely anway, and avoid overlappings.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

> do not make the core of Mozilla dependent on NSS header files, because 
> the crypto code is fully external and modular

Of course, the same may be said for NSPR.  It is fully external and modular.
So it seems that the arguments against making mozilla core dependent on 
NSS also apply equally to making it not dependent on NSPR.

Comment 2

[Kai Engert (:KaiE:)]

(In reply to comment #1)
> > do not make the core of Mozilla dependent on NSS header files, because 
> > the crypto code is fully external and modular
> 
> Of course, the same may be said for NSPR.  It is fully external and modular.
> So it seems that the arguments against making mozilla core dependent on 
> NSS also apply equally to making it not dependent on NSPR.

I don't buy that argument, because Mozilla depends 100% on NSPR, but only a very small part - PSM - depends on NSS:

Comment 3

[Wan-Teh Chang]

Kai, could you consider the design that Mozilla's error handling code
calls error code handler functions registered by the components?
Then PSM can register an error handler for NSS error codes.

Comment 4

[Kai Engert (:KaiE:)]

Ok, you have convinced me that this needs to get solved outside of NSPR.

In the latest patch attached to bug 107491 I am using the approach that Wan-Teh suggested in comment 3.

Closing this bug as WONTFIX.