Skip to content

Conversation

@AJMansfield
Copy link
Contributor

@AJMansfield AJMansfield commented Dec 18, 2025

Summary

This PR collects together all of the macro constants associated with the "typecode" value used across several different modules to encode information about the type identity of an associated pointer or memory buffer. These values were previously scattered across the codebase, often leading to confusion about the C API, resulting in e.g. defective memoryview objects with no typecode except for the read-write flag.

With this change:

  • Anyone searching for information about the typecode values is led to a single location where they are all listed.
  • Other aliases for the same types can be used transparently: For instance, MP_TYPECODE_C(custom_typedefed_int_t) would automatically pick the appropriate typecode letter at compile time thanks to the semantics of _Generic.
  • Instances where an incorrect association from typecode to C type have been made will be a lot more obvious to inspection. For instance, take the following bug:
    case 'q':
        long double *x = obj;
        return quad_float_op(*x);
    Maybe you already know reflexively that that's NOT actually what 'q' means, but it's still a lot easier to spot if you instead write it like:
    case MP_TYPECODE_C(long long int):
        long double *x = obj;
        return quad_float_op(*x);

Testing

I've run the test suite across unix and rp2 on my own hardware. All extant tests pass; though as a pure refactor, this change can't be checked directly.

Some of the changes touch port-specific code for devices I don't have access to; hopefully CI will catch anything aggressively defective, but this ought to be tested on those other devices.

Trade-offs and Alternatives

Using _Generic limits compatibility to C11 and above. If that's a problem, potentially separate macros for each type could be declared instead --- but that's only marginally useful than single-letter typecodes.

Potentially, it would be better to use the stdint names for the typecodes, i.e. uint8_t instead of unsigned char; and in several of the places I've refactored there might be a more semantic typename to use as the argument --- the actual typename of the associated buffer, or perhaps even a typeof expression involving that buffer.

Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
Also moving it from objarray.h to binary.h.

Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
@github-actions
Copy link

Code size report:

Reference:  esp32/machine_sdcard: Fix SDMMC slot assignment for non-default slots. [e67d4a2]
Comparison: py/binary: Use MP_TYPECODE_C instead of literal chars. [merge of 9b868cf]
  mpy-cross:    +0 +0.000% 
   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

@codecov
Copy link

codecov bot commented Dec 18, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.38%. Comparing base (3f796b6) to head (9b868cf).
⚠️ Report is 24 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #18590      +/-   ##
==========================================
- Coverage   98.38%   98.38%   -0.01%     
==========================================
  Files         171      171              
  Lines       22301    22300       -1     
==========================================
- Hits        21940    21939       -1     
  Misses        361      361              

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

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

Successfully merging this pull request may close these issues.

1 participant