Inconsistent error checking in cuda.bindings

[yangcal]

It seems some of the cuda bindings check errors before returning while the others do not, any reason for this? e.g, cudaMalloc checks return status while cudaFree does not.

This leads to inconsistent user experience. A colleague found that cudaFree didn't do error check and assumed that he now needs to manually check return status for all binding calls.

[leofang]

For driver/runtime/nvrtc, you always have to check the returned error code (the first element of the returned tuple) due to unfortunate design decisions that predated both of us.

We recently moved to empty out the remaining parts of the tuple by checking the error internally, only because we found that if an error is occurred, it is generally unsafe for users to access the returned objects. It is however a backward compatible change.

We do want to break the world perhaps by CUDA 14, and align the three modules with all other "new-style" bindings that we offer, and turn error-code checking into exception handling on the user land.

Alternatively (without waiting for us committing and changing it by the next CUDA major release), just use cuda.core and stay away from bindings 🙂

[yangcal]

acknowledged