grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 1/2] json: Add function to unescape JSON-encoded strings


From: Patrick Steinhardt
Subject: Re: [PATCH v3 1/2] json: Add function to unescape JSON-encoded strings
Date: Mon, 6 Jun 2022 07:18:28 +0200

On Sun, Jun 05, 2022 at 02:00:44PM -0500, Glenn Washburn wrote:
> On Mon, 30 May 2022 18:01:01 +0200
> Patrick Steinhardt <ps@pks.im> wrote:
> 
> > JSON strings require certain characters to be encoded, either by using a
> > single reverse solidus character "\" for a set of popular characters, or
> > by using a Unicode representation of "\uXXXXX". The jsmn library doesn't
> > handle unescaping for us, so we must implement this functionality for
> > ourselves.
> > 
> > Add a new function `grub_json_unescape ()` that takes a potentially
> > escaped JSON string as input and returns a new unescaped string.
> > 
> > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> > ---
> >  grub-core/lib/json/json.c | 98 +++++++++++++++++++++++++++++++++++++++
> >  grub-core/lib/json/json.h | 12 +++++
> >  2 files changed, 110 insertions(+)
> > 
> > diff --git a/grub-core/lib/json/json.c b/grub-core/lib/json/json.c
> > index 1c20c75ea..3e5e25f79 100644
> > --- a/grub-core/lib/json/json.c
> > +++ b/grub-core/lib/json/json.c
> > @@ -262,3 +262,101 @@ grub_json_getint64 (grub_int64_t *out, const 
> > grub_json_t *parent, const char *ke
> >  
> >    return GRUB_ERR_NONE;
> >  }
> > +
> > +grub_err_t
> > +grub_json_unescape (char **out, size_t *outlen, const char *in, size_t 
> > inlen)
> 
> Why not grub_size_t instead of size_t?
> 
> > +{
> > +  grub_err_t ret = GRUB_ERR_NONE;
> > +  size_t inpos, resultpos;
> 
> Same here.
> 
> > +  char *result;
> > +
> > +  result = grub_calloc (1, inlen + 1);
> 
> Should check for grub_calloc failure.
> 
> I like the idea of being able to do an inplace conversion if in ==
> *out, which would save on memory and be safe as the out string length
> should always be less than or equal to the length of the in string.
> I'll admit its not really necessary for the current use-case.
[snip]

Yeah, I thought about this, and in fact my first iteration did exactly
that. But it complicates the interface somewhat given that you now have
to pass in the caller-allocated size, return the end result's size and
also have to somehow handle NUL-terminating the result. So altogether it
added complexity and felt a lot more fragile compared to just allocating
the result array.

Patrick

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]