Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch from signed to unsigned interpretation of Object IDs is breaking change for existing apps. #75

Open
laurenrad opened this issue Nov 21, 2023 · 1 comment

Comments

@laurenrad
Copy link
Contributor

In PR #31 , along with various other changes, it appears that thoughout the code, the interpretation of Object ID values in SWI calls was changed from signed to unsigned (most notably, in base.py, when the object is created and the ID fetched from the Toolbox).

I noticed while testing the new version with my existing app code that I was repeatedly getting "Python int too large to convert to C long" errors; this appears to be because my code contains various calls to Toolbox SWIs directly for functionality that isn't in the library, and these calls are passing the IDs as signed values, as was expected in 1.0.x. However, now there is a mismatch so all code of this sort is broken.

FWIW, the c headers for the Toolbox veneers specify ObjectId and ComponentId was typedefs for int, but the important thing here is consistency, really. So I propose that if this isn't swapped back entirely, perhaps at least there could be an option to set to have riscos-toolbox cast these back to signed for me to avoid having to change a lot of code points.

If needed, this can be reliably reproduced by loading the test file for my application, RLook:
https://github.com/laurenrad/RLook

Or, this is likely to occur variously in TBPTest:
https://github.com/laurenrad/TBPTest

@c-jo
Copy link
Owner

c-jo commented Nov 27, 2023

This is a bit of a tricky one, they probably should be unsigned, but as they weren't before and as such I'm tempted to put them back to signed for now and try to address the underlying issues later. This may well result in a breaking change, but I'd like to get a better handle on that before I do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants