mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2025-04-10 18:34:23 +00:00
0af864b4b2
Summary:
This patch finishes the python3-ification of the lldb-server test suite.
It reverts the partial attempt in r352709 to encode/decode the string
via utf8 before writing to the socket. This wasn't enough because the
gdb-remote protocol can sometimes (but not very often) carry binary
data, and the utf8 codec chokes on that. Instead I add utility functions
to the "seven" module for performing "identity" transformations on the
byte data. This basically drills back the hole in the python type system
that the string/bytes distinction was supposed to plug. That is not
ideal, but was the best solution of the alternatives I could come up
with. The options I considered were:
- make use of the type system to add type safety to the test suite: This
required making a lot of changes to the test suite, since most of the
strings would now become byte objects instead, and it was not even
fully clear to me where to draw the line. One extreme solution would
be to just use byte objects everywhere, as the protocol doesn't
support non-ascii characters anyway. However, this appeared to be:
a) weird, because most of the protocol actually deals with strings,
but we would have to prefix everything with 'b'
b) clunky, because the handling of the bytes objects is sufficiently
different in PY2 and PY3 (e.g. b'a'[0] is a string in PY2, but an
int in PY3).
- using the latin1 codec (which gives an identity transformation for the
first 256 code points of unicode) instead of the custom
bytes_to_string functions. This almost could work, but it was still
slightly different between python 2 and 3, because in PY2 in would
return a unicode object, which would then cause problems when
combined with regular strings if it contained 8-bit chars.
With this in mind, I think the best solution for the time being is to
just coerce everything into the string type as early as possible, and
have things proceed indentically on both python versions. Once we stop
supporting python3, we can revisit the idea of using bytes objects more
prevasively.
Reviewers: davide, zturner, serge-sans-paille
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D58177
llvm-svn: 354106
52 lines
1.6 KiB
Python
52 lines
1.6 KiB
Python
import binascii
|
|
import six
|
|
|
|
if six.PY2:
|
|
import commands
|
|
get_command_output = commands.getoutput
|
|
get_command_status_output = commands.getstatusoutput
|
|
|
|
cmp_ = cmp
|
|
else:
|
|
def get_command_status_output(command):
|
|
try:
|
|
import subprocess
|
|
return (
|
|
0,
|
|
subprocess.check_output(
|
|
command,
|
|
shell=True,
|
|
universal_newlines=True).rstrip())
|
|
except subprocess.CalledProcessError as e:
|
|
return (e.returncode, e.output)
|
|
|
|
def get_command_output(command):
|
|
return get_command_status_output(command)[1]
|
|
|
|
cmp_ = lambda x, y: (x > y) - (x < y)
|
|
|
|
def bitcast_to_string(b):
|
|
"""
|
|
Take a string(PY2) or a bytes(PY3) object and return a string. The returned
|
|
string contains the exact same bytes as the input object (latin1 <-> unicode
|
|
transformation is an identity operation for the first 256 code points).
|
|
"""
|
|
return b if six.PY2 else b.decode("latin1")
|
|
|
|
def bitcast_to_bytes(s):
|
|
"""
|
|
Take a string and return a string(PY2) or a bytes(PY3) object. The returned
|
|
object contains the exact same bytes as the input string. (latin1 <->
|
|
unicode transformation is an identity operation for the first 256 code
|
|
points).
|
|
"""
|
|
return s if six.PY2 else s.encode("latin1")
|
|
|
|
def unhexlify(hexstr):
|
|
"""Hex-decode a string. The result is always a string."""
|
|
return bitcast_to_string(binascii.unhexlify(hexstr))
|
|
|
|
def hexlify(data):
|
|
"""Hex-encode string data. The result if always a string."""
|
|
return bitcast_to_string(binascii.hexlify(bitcast_to_bytes(data)))
|