You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there are many instances in encryption code and ASN processing where literal hardcoded errors are used, like -1, -2, etc.
This usually happens when negative value is considered an error, recoverable or not, returned from operation.
The problem is that this is a little bit messy, because there is no information on meaning of -1 vs -2, nor reason why some functions only return -1 on any error. Callers just usually check ret to be >=0 for success, and that seems to be enough, so maybe having so many codes is not useful at all?
Solution
Proposed solution would be to define either full range of error identifiers for negative values used, or cut down returned values to SUCCESS and FAIL values and process only these.
The text was updated successfully, but these errors were encountered:
The issue
Currently there are many instances in encryption code and ASN processing where literal hardcoded errors are used, like -1, -2, etc.
This usually happens when negative value is considered an error, recoverable or not, returned from operation.
The problem is that this is a little bit messy, because there is no information on meaning of -1 vs -2, nor reason why some functions only return -1 on any error. Callers just usually check ret to be >=0 for success, and that seems to be enough, so maybe having so many codes is not useful at all?
Solution
Proposed solution would be to define either full range of error identifiers for negative values used, or cut down returned values to SUCCESS and FAIL values and process only these.
The text was updated successfully, but these errors were encountered: