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

Code obj support #265

Merged
merged 3 commits into from
Jun 16, 2022
Merged

Code obj support #265

merged 3 commits into from
Jun 16, 2022

Conversation

clubby789
Copy link
Contributor

For both tools:

  • Adds a boolean -c flag and a string -v paramater for specifying 'this file is a code object' and the Python version respectively
  • Adds a new method to load a PycModule from a code object (skips header loading and manually sets magic from major/minor)
  • Add an INVALID variant to the PycMagic enum for an invalid magic value

These requires the Python version to be specified as the Pyc header
magic is not present.
pyc_module.cpp Outdated Show resolved Hide resolved
pyc_module.cpp Outdated
Comment on lines 217 to 218
m_maj = major;
m_min = minor;
Copy link
Owner

Choose a reason for hiding this comment

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

setVersion() already sets these... Additionally, since we're parsing the version directly, we may want to have a way to indicate that Unicode mode is being used for Python 1.6-2.7. Perhaps checking for a 'u' suffix to the version number would be sufficient?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Isn't the CO_FUTURE_UNICODE_LITERALS flag set within the code object itself, and wouldn't need to be explicitly added?

Copy link
Owner

@zrax zrax Jun 16, 2022

Choose a reason for hiding this comment

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

The unicode bytecode magic number is used when Python 2.x is run with the (undocumented) -U flag, and is not related to the CO_FUTURE_UNICODE_LITERALS code flag -- the two can be present or absent independently of each other...

However, from looking at the code, it looks like the only place we actually use m_unicode is when printing the Python version in the comments... There may be something missing there that will need to be addressed eventually, but since this flag was rarely used and doesn't have any meaningful impact on the output, I suppose this can be ignored for now.

pyc_module.cpp Outdated Show resolved Hide resolved
pyc_module.cpp Outdated Show resolved Hide resolved
pyc_module.cpp Outdated Show resolved Hide resolved
pycdas.cpp Outdated Show resolved Hide resolved
pycdas.cpp Outdated Show resolved Hide resolved
pycdc.cpp Outdated Show resolved Hide resolved
pycdc.cpp Outdated Show resolved Hide resolved
@zrax zrax merged commit b0ce842 into zrax:master Jun 16, 2022
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.

2 participants