arizvisa / syringe Goto Github PK

yea, do this. you've been slacking for like almost a decade now.

Talking to myself....Singing to myself...Wooooooo!

Please fix the following issues for Python3:

• Parenthesized Prints
• New-Style Exceptions
• Map and Zip Iterables
• Dictionary Changes
• Strings versus Bytes
• Array.Array module deprecations
• Comparisons (Hashes)
• Comparisons (Equivalency)
• Integer Division
• Package Imports
• ByteCode Generation
• Serialization Magic Tricks
• Parameterized Packing/Unpacking
• Class-Object Attributes

Would be cool to represent code and pointers to code with a native code type in ptypes.

This way a user wouldn't need to manually transform the semantics of a ptype instance into a way to execute it. The downside of this is that depending on how it's implemented, we could end up forcing the user into dispatching to their referenced code with whatever methodology we choose.

Ideally we want to avoid pigeon-holing the user so that users can interpret a code type using whatever implementation they choose. This way we can keep the flexibility of ptypes. We'd also want to dumb down the interface so that users can interpret the code in whatever context is relevant to them (running in the current process, remote process, in an emulator, etc.) and also allow them to describe the calling convention of whatever it is that they're trying to interpret.

There was a preliminary implementation of this under the ptypes.code module that tied it to the intel architecture using the udis package and the table-based instruction length disassembler that went into the ia32 library module. It ended up not being used for anything but shellcode, however, due to the reasons that were just mentioned. I'd like the interface for disassemblling the type and interpreting it to be exposed to the user in some global way rather than requiring the user to describe it specific to the type during its creation. Maybe something similar to the byteorder interface that is used for both integrals and binary types.

This is just a placeholder to completely deprecate the break_on_zero_sized_element configuration option which is used to specify whether to user wants to include zero-sized array elements for any kind of terminated array. Allowing zero-sized array elements for terminated arrays allows for an infinite recursion issue due to the existence of arrays that are bounded by size.

The ptype.definition class needs to be refactored so that it's easier for an implementor to influence the way that it works. This way one can easily modify it to support more complex type lookup schemes than how ptype.definition was originally intended. At the moment, the internal methods, __set__, __get__, and __has__ are the only ones that can be used by an implementor. If this functionality is expanded by allowing them to take arbitrary parameters and implementing methods that can be used to lookup within the class, we can avoid the implementor having to completely implement their own custom definition to support their needs.