Devicetree Compiler
 help / color / mirror / Atom feed
From: Luca Weiss <luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org>
To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	David Gibson
	<david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
Cc: Devicetree Compiler
	<devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 1/4] pylibfdt: add Property.as_stringlist()
Date: Thu, 20 Jan 2022 20:24:31 +0100	[thread overview]
Message-ID: <12903489.O9o76ZdvQC@g550jk> (raw)
In-Reply-To: <YeaRlvVf19o4Qnzm@yekko>

Hi,

On Dienstag, 18. Jänner 2022 11:08:22 CET David Gibson wrote:
> On Wed, Jan 05, 2022 at 04:48:31PM -0600, Rob Herring wrote:
> > On Sat, Dec 25, 2021 at 7:26 AM Luca Weiss <luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org> wrote:
> > > Add a new method for decoding a string list property, useful for e.g.
> > > the "reg-names" property.
> > > 
> > > Also add a test for the new method.
> > > 
> > > Signed-off-by: Luca Weiss <luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org>
> > > ---
> > > 
> > >  pylibfdt/libfdt.i       | 7 +++++++
> > >  tests/pylibfdt_tests.py | 8 ++++++++
> > >  2 files changed, 15 insertions(+)
> > > 
> > > diff --git a/pylibfdt/libfdt.i b/pylibfdt/libfdt.i
> > > index 9ccc57b..c81b504 100644
> > > --- a/pylibfdt/libfdt.i
> > > +++ b/pylibfdt/libfdt.i
> > > 
> > > @@ -724,6 +724,13 @@ class Property(bytearray):
> > >              raise ValueError('Property contains embedded nul
> > >              characters')
> > >          
> > >          return self[:-1].decode('utf-8')
> > > 
> > > +    def as_stringlist(self):
> > > +        """Unicode is supported by decoding from UTF-8"""
> > > +        if self[-1] != 0:
> > > +            raise ValueError('Property lacks nul termination')
> > > +        parts = self[:-1].split(b'\x00')
> > > +        return list(map(lambda x: x.decode('utf-8'), parts))
> > 
> > Doesn't this result in multiple decode() calls when a single one would
> > work:
> > 
> > return data[:-1].decode(encoding='ascii').split('\0')
> 
> Uh.. I guess?  I feel like the split-then-decode makes more logical
> sense, since it's splitting a bytestring, then decoding the pieces as
> utf-8 strings.  That makes sense to me given that raw properties are
> bytestrings and can included multiple different datatypes and
> encodings in general.
> 
> In this specific case, decode-then-split would be fine as well, since
> \u00000 works as a separator unambiguously, but it still seems
> conceptually muddier to me.

The reason I made it this way was mostly because I didn't know you could have 
null bytes present in str.decode, I just remember horrible UnicodeDecodeErrors 
on invalid input from other projects.
If wanted I can make a patch changing to just one str.decode call as yes, it's 
surely more efficient than doing multiple. But it's also not like there will be 
100 parts of this property that's being decoded in a performance critical 
application so I think it's also okay like that.

Let me know what you think.
Regards
Luca



  reply	other threads:[~2022-01-20 19:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-25 13:25 [PATCH 0/4] Add new helpers to pylibfdt Luca Weiss
     [not found] ` <20211225132558.167123-1-luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org>
2021-12-25 13:25   ` [PATCH 1/4] pylibfdt: add Property.as_stringlist() Luca Weiss
     [not found]     ` <20211225132558.167123-2-luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org>
2021-12-28  4:29       ` David Gibson
2022-01-05 22:48       ` Rob Herring
     [not found]         ` <CAL_JsqLvQdm1kqMED8G03LEsm+xgyY2A+F+FD8DYeAy5o+eiGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-01-18 10:08           ` David Gibson
2022-01-20 19:24             ` Luca Weiss [this message]
2022-01-21  0:12               ` David Gibson
2021-12-25 13:25   ` [PATCH 2/4] pylibfdt: add Property.as_*int*_array() Luca Weiss
     [not found]     ` <20211225132558.167123-3-luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org>
2021-12-28  4:30       ` David Gibson
2021-12-25 13:25   ` [PATCH 3/4] pylibfdt: add FdtRo.get_path() Luca Weiss
     [not found]     ` <20211225132558.167123-4-luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org>
2021-12-28  4:33       ` David Gibson
2021-12-25 13:25   ` [PATCH 4/4] pylibfdt: add FdtRo.getprop_or_none() Luca Weiss
     [not found]     ` <20211225132558.167123-5-luca-IfPCFPJWly+lVyrhU4qvOw@public.gmane.org>
2021-12-28  5:20       ` David Gibson
2021-12-28  8:34       ` Simon Glass
     [not found]         ` <CAPnjgZ3wun92Q1vMSEem9CH6A8MWNbKZNaepf4j4Ttmf-GNPtQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-01-22 10:36           ` Luca Weiss
2022-01-24 17:57             ` Simon Glass
     [not found]               ` <CAPnjgZ1NX2Q884T_LNUOLJT8=RKZXEj2z7uxzQF4MrHiKObZvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-01-24 20:50                 ` Luca Weiss
2022-01-24 21:28                   ` Simon Glass
2022-01-25  4:50             ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12903489.O9o76ZdvQC@g550jk \
    --to=luca-ifpcfpjwly+lvyrhu4qvow@public.gmane.org \
    --cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
    --cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox