Hello.
On 07/16/2018 01:33 AM, Simon Glass wrote:
Hi Petr,
On 12 July 2018 at 08:10, <frenzy@xxxxxxxxx> wrote:
From: Petr Viktorin <pviktori@xxxxxxxxxx>
Signed-off-by: Petr Viktorin <pviktori@xxxxxxxxxx>
---
pylibfdt/libfdt.i | 4 ++++
tests/pylibfdt_tests.py | 12 +++++++-----
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/pylibfdt/libfdt.i b/pylibfdt/libfdt.i
index 9c0dcdc..da8d56b 100644
--- a/pylibfdt/libfdt.i
+++ b/pylibfdt/libfdt.i
@@ -759,6 +759,10 @@ typedef uint32_t fdt32_t;
/* typemap used for fdt_setprop() */
%typemap(in) (const void *val) {
%#if PY_VERSION_HEX >= 0x03000000
+ if (!PyBytes_Check($input)) {
+ SWIG_exception_fail(SWIG_TypeError, "bytes expected in method '" "$symname"
+ "', argument " "$argnum"" of type '" "$type""'");
+ }
Can you please expand the commit message? Does this mean that it
cannot take a string in Python 3? Is that because we always end up
with bytes in that case?
Yes. Should this method be compatible with unicode property name? I've
checked tests and property name is always bytes and unicode is used only
as a property value.
I am not sure if it would be simple to support unicode property name.
$1 = PyBytes_AsString($input);
%#else
$1 = PyString_AsString($input); /* char *str */
diff --git a/tests/pylibfdt_tests.py b/tests/pylibfdt_tests.py
index e1204f8..348cb09 100644
--- a/tests/pylibfdt_tests.py
+++ b/tests/pylibfdt_tests.py
@@ -67,6 +67,8 @@ TEST_VALUE64_1H = 0xdeadbeef
TEST_VALUE64_1L = 0x01abcdef
TEST_VALUE64_1 = (TEST_VALUE64_1H << 32) | TEST_VALUE64_1L
+TEST_BYTES_1 = b'hello world'
+
TEST_STRING_1 = 'hello world'
TEST_STRING_2 = 'hi world'
try:
@@ -413,21 +415,21 @@ class PyLibfdtTests(unittest.TestCase):
def testSetProp(self):
"""Test that we can update and create properties"""
node = self.fdt.path_offset('/subnode@1')
- self.fdt.setprop(node, 'compatible', TEST_STRING_1)
- self.assertEquals(TEST_STRING_1, self.fdt.getprop(node, 'compatible'))
+ self.fdt.setprop(node, 'compatible', TEST_BYTES_1)
+ self.assertEquals(TEST_BYTES_1, self.fdt.getprop(node, 'compatible'))
Are we not losing test coverage for Python 2? Again, a commit message
might help here.
I think that no. The coverage is the same because 'hello world' and
b'hello world' is the same in Python 2 so the new name makes it more
clear just for Python 3.
# Check that this property is missing, and that we don't have space to
# add it
self.assertEquals(-libfdt.NOTFOUND,
self.fdt.getprop(node, 'missing', QUIET_NOTFOUND))
self.assertEquals(-libfdt.NOSPACE,
- self.fdt.setprop(node, 'missing', TEST_STRING_1,
+ self.fdt.setprop(node, 'missing', TEST_BYTES_1,
quiet=(libfdt.NOSPACE,)))
# Expand the device tree so we now have room
self.fdt.resize(self.fdt.totalsize() + 50)
- self.fdt.setprop(node, 'missing', TEST_STRING_1)
- self.assertEquals(TEST_STRING_1, self.fdt.getprop(node, 'missing'))
+ self.fdt.setprop(node, 'missing', TEST_BYTES_1)
+ self.assertEquals(TEST_BYTES_1, self.fdt.getprop(node, 'missing'))
def testSetPropU32(self):
"""Test that we can update and create integer properties"""
--
2.17.1
Regards,
Simon
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
