8000 Incorrect setting of class.base.type in some examples · Issue #17327 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content
8000

Incorrect setting of class.base.type in some examples #17327

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
Open
dubiousjim opened this issue May 20, 2025 · 0 comments
Open

Incorrect setting of class.base.type in some examples #17327

dubiousjim opened this issue May 20, 2025 · 0 comments
Labels
bug

Comments

@dubiousjim
Copy link
Contributor
dubiousjim commented May 20, 2025 •
edited
Loading

Port, board and/or hardware

unix/standard port, PiZero2 board, but irrelevant to this issue

MicroPython version

MicroPython v1.25.0 on 2025-04-30; linux [GCC 14.2.0] version

Reproduction

Here are some lines from native module example code.

  1. examples/natmod/btree/btree_c.c has: 
    btree_type.base.type = (void*)&mp_fun_table.type_type;
  2. examples/natmod/re/re.c has: 
    match_type.base.type = (void*)&mp_fun_table.type_type;
  3. examples/natmod/deflate/deflate.c has: 
    deflateio_type.base.type = mp_fun_table.type_type;
  4. examples/natmod/framebuf/framebuf.c has: 
    mp_type_framebuf.base.type = (void*)&mp_type_type;

The last is a bit confusing. Because all of these files #include "py/dynruntime.h", it gets macro-expanded to:

mp_type_framebuf.base.type = (void*)&(*mp_fun_table.type_type);

And so patterns the same as the third option. That struct field holds a pointer to the variable that in the interpreter is called mp_type_type, but which is not directly visible to the dynamic native modules.

So cases 3 and 4 are setting the base.type to a (const mp_obj_type_t *), whose value is &mp_type_type (this is the const type object defined in py/objtype.c, not the macro defined in py/dynruntime.h).

Whereas cases 1 and 2 are setting the base.type to a pointer to a struct field that holds such a (const mp_obj_type_t *). They're one pointer level further removed. This is just not noticed because they are cast to (void *).

I believe that cases 1 and 2 are mistakes, and that they should be following the pattern in case 3 or case 4. Am I right?

Expected behaviour

No response

Observed behaviour

See code analysis above. Examples as-is compile and run without issue; but I think this is just because the type is being treated as opaque and not being dereferenced.

Additional Information

No, I've provided everything above.

Code of Conduct

Yes, I agree
@dubiousjim dubiousjim added the bug label May 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@dubiousjim
0