Skip to content

Sign and type issues with XNET status codes #250

@d-bohls

Description

@d-bohls

Pulled from discussion in #233.

There are a couple of issues with status codes:

Sign issue:
The C API treats status as an i32. Positive codes are a warning and negative codes are an error. The python API treats status as a u32. It's an error if the MSB is set, and a warning otherwise. If the user is dealing with the status code in hex, this is no big deal. However, equivalent error codes as int will not match between the C API and the python API. This doesn't seem ideal to me. Do we care?

Type issue:
In _cconsts.py line 8 we define NX_STATUS_ERROR = (0x80000000) which comes from the C API and is used as a bit mask for the MSB on i32 status codes. When we do this in python 2.7, NX_ERROR_BASE get promoted from an int to a long because 3220582400 (the unsigned value of 0x80000000) does not fit in 4 bytes for a signed python int. If we set NX_STATUS_ERROR to -2147483648 instead (the i32 value of 0x80000000), this promotion to long doesn't happen. Python 3.6 did away with long so NX_STATUS_ERROR stays an int. So far, the only effect I know of due to this issue is that I ran into difficulty trying to add typing checks on status codes, since codes are a long in 2.7 and an int in 3.6, and 3.6 doesn't know about longs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions