3 ms·

> memory-unsafety is difficult to accidentally reach from regular Python code Can you give an example of Python (source) code that isn't memory safe? I assume

by pansa2 2y ago

> memory-unsafety is difficult to accidentally reach from regular Python code Can you give an example of Python (source) code that isn't memory safe? I assumed Python would be similar to Lua in this respect - the interpreter is memory safe no matter what source code you give it, but when it comes to custom bytecode, all bets are off.

Retr0id 2y ago
My favourite unsafe one-liner: eval((lambda:0).__code__.replace(co_consts=())) This one is slightly cheat-y because it does modify the code object, just not the bytecode itself. "Purer" unsafety issues are treated as bugs and patched, but that doesn't stop them from existing periodically. I don't have a specific example on-hand but I bet you can find some in here: https://github.com/search?q=repo%3Apython%2Fcpython+segmentation+fault&type=issues https://github.com/search?q=repo%3Apython%2Fcpython+segmenta... Edit: This one is a decent example (and hasn't been fixed for a long time) https://github.com/python/cpython/issues/74957 https://github.com/python/cpython/issues/74957
- pansa2 2y ago
  > "Purer" unsafety issues are treated as bugs and patched, but that doesn't stop them from existing periodically. Yeah, the same is true for Lua (search for "segfault" here: https://www.lua.org/bugs.html https://www.lua.org/bugs.html). The difference is that Lua tends to have far fewer bugs overall than Python, mostly because it's so much simpler.
- bubaumba 2y ago
  That was intentional. And intentionally quite a lot of safe thing can be broken.
  - Retr0id 2y ago
    Whoever opened issue #74957 appeared to have encountered it accidentally. But my initial point was, if you're writing raw bytecode, you're much more likely to hit memory unsafety issues relative to normal Python code.
tekknolagi 2y ago
Anything using codecs, especially CJK. The amount of scary stuff we found when reimplementing it was... Well, scary

by pansa2 2y ago

Retr0id 2y ago

My favourite unsafe one-liner: eval((lambda:0).__code__.replace(co_consts=())) This one is slightly cheat-y because it does modify the code object, just not the bytecode itself. "Purer" unsafety issues are treated as bugs and patched, but that doesn't stop them from existing periodically. I don't have a specific example on-hand but I bet you can find some in here: https://github.com/search?q=repo%3Apython%2Fcpython+segmentation+fault&type=issues https://github.com/search?q=repo%3Apython%2Fcpython+segmenta... Edit: This one is a decent example (and hasn't been fixed for a long time) https://github.com/python/cpython/issues/74957 https://github.com/python/cpython/issues/74957

pansa2 2y ago
> "Purer" unsafety issues are treated as bugs and patched, but that doesn't stop them from existing periodically. Yeah, the same is true for Lua (search for "segfault" here: https://www.lua.org/bugs.html https://www.lua.org/bugs.html). The difference is that Lua tends to have far fewer bugs overall than Python, mostly because it's so much simpler.
bubaumba 2y ago
That was intentional. And intentionally quite a lot of safe thing can be broken.
- Retr0id 2y ago
  Whoever opened issue #74957 appeared to have encountered it accidentally. But my initial point was, if you're writing raw bytecode, you're much more likely to hit memory unsafety issues relative to normal Python code.

tekknolagi 2y ago

Anything using codecs, especially CJK. The amount of scary stuff we found when reimplementing it was... Well, scary