Skip to content

extmod/uctypes: fix addressof when returning large values #16440

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 2 commits into from
Dec 18, 2024
Merged

extmod/uctypes: fix addressof when returning large values #16440

merged 2 commits into from
Dec 18, 2024

Conversation

dpgeorge
Copy link
Member

Summary

This fixes uctypes.addressof() so it always returns positive values.

Prior to this fix it would return negative addresses for values that were larger than the maximum small-int value.

Testing

Test added as part of this PR which runs under CI. Also tested on PYBD_SF6 (test failed prior to the fix here, now passes).

@dpgeorge dpgeorge added the extmod Relates to extmod/ directory in source label Dec 17, 2024
@codecov Codecov
Copy link

codecov bot commented Dec 17, 2024 •
edited
Loading

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.57%. Comparing base (23bfa95) to head (d10cda6).
Report is 2 commits behind head on master.

Additional details and impacted files 
@@           Coverage Diff           @@
##           master   #16440   +/-   ##
=======================================
  Coverage   98.57%   98.57%           
=======================================
  Files         164      164           
  Lines       21349    21349           
=======================================
  Hits        21045    21045           
  Misses        304      304

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

projectgus
projectgus reviewed Dec 17, 2024
View reviewed changes
extmod/moductypes.c Outdated
@@ -602,7 +602,7 @@ static mp_obj_t uctypes_struct_unary_op(mp_unary_op_t op, mp_obj_t self_in) {
uint agg_type = GET_TYPE(offset, AGG_TYPE_BITS);
if (agg_type == PTR) {
byte *p = *(void **)self->addr;
return mp_obj_new_int((mp_int_t)(uintptr_t)p);
return mp_obj_new_int_from_uint((mp_int_t)(uintptr_t)p);
Copy link
Contributor

@projectgus projectgus Dec 17, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return mp_obj_new_int_from_uint((mp_int_t)(uintptr_t)p);
return mp_obj_new_int_from_uint((uintptr_t)p);

(Takes out the unnecessary and maybe-UB-although-realistically-not cast.)

I ran into this last week testing #16311 V2 changes on qemu where the RAM range is quite high in the 32-bit space.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I hit this on qemu as well, testing #8381, which checks the address of ROMFS files are within the address of the ROMFS itself.

@github-actions GitHub Actions
Copy link

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

dlech
dlech reviewed Dec 17, 2024
View reviewed changes
extmod/moductypes.c Outdated
@@ -602,7 +602,7 @@ static mp_obj_t uctypes_struct_unary_op(mp_unary_op_t op, mp_obj_t self_in) {
uint agg_type = GET_TYPE(offset, AGG_TYPE_BITS);
if (agg_type == PTR) {
byte *p = *(void **)self->addr;
return mp_obj_new_int((mp_int_t)(uintptr_t)p);
return mp_obj_new_int_from_uint((mp_int_t)(uintptr_t)p);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return mp_obj_new_int_from_uint((mp_int_t)(uintptr_t)p);
return mp_obj_new_int_from_uint((uintptr_t)p);

Probably don't need the 2nd cast since the parameter type is mp_uint_t already.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, I'm too slow, Angus beat me to it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two out of two reviewers agree! 😁

@dpgeorge
Copy link
Member Author

This was split out from #8381.

@dpgeorge
extmod/moductypes: Fix large return values of addressof and INT_MAYBE.
8970ede 
So they don't return a negative number for an address (prior to this fix
they would return negative addresses for values that were larger than the
maximum small-int value).

Signed-off-by: Damien George <damien@micropython.org>
@dpgeorge
tests/extmod: Add test for uctypes.addressof function.
d10cda6 
Signed-off-by: Damien George <damien@micropython.org>
@dpgeorge dpgeorge force-pushed the extmod-uctypes-fix-addressof-large-value branch from cc2ea4c to d10cda6 Compare December 18, 2024 00:01
@dpgeorge
Copy link
Member Author

Thanks for the quick review! I made the recommended change. It should be fine, because mp_uint_t is always guaranteed to be at least as big as a system pointer (so it can be used to store mp_obj_t which can point to arbitrary memory addresses).

@dpgeorge dpgeorge merged commit d10cda6 into micropython:master Dec 18, 2024
63 checks passed
@dpgeorge dpgeorge deleted the extmod-uctypes-fix-addressof-large-value branch December 18, 2024 00:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dlech dlech dlech left review comments

@projectgus projectgus projectgus approved these changes

Assignees
No one assigned
Labels
extmod Relates to extmod/ directory in source
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@dpgeorge @projectgus @dlech
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy