From: Patrick Steinhardt <ps@pks.im>
To: The development of GNU GRUB <grub-devel@gnu.org>
Cc: Max Tottenham <mtottenh@akamai.com>
Subject: Re: [PATCH v2 2/6] json: Implement wrapping interface
Date: Tue, 5 Nov 2019 14:12:13 +0100 [thread overview]
Message-ID: <20191105131213.GA177916@ncase> (raw)
In-Reply-To: <20191105125438.GA20442@lon-lp55b.london.corp.akamai.com>
[-- Attachment #1: Type: text/plain, Size: 3737 bytes --]
On Tue, Nov 05, 2019 at 12:54:38PM +0000, Max Tottenham via Grub-devel wrote:
> On 11/05, Patrick Steinhardt wrote:
> > +grub_err_t
> > +grub_json_parse (grub_json_t **out, const char *string, grub_size_t string_len)
> > +{
> > + grub_size_t ntokens = 128;
> > + grub_json_t *json = NULL;
> > + jsmn_parser parser;
> > + grub_err_t err;
> > + int jsmn_err;
> > +
> > + json = grub_zalloc (sizeof (*json));
> > + if (!json)
> > + return GRUB_ERR_OUT_OF_MEMORY;
> > + json->idx = 0;
> > + json->string = grub_strndup (string, string_len);
>
> I'm assuming the idea here is to ensure that the lifetime of the
> returned grub_json_t doesn't depend on the lifetime of the input string?
>
> This concerns me a little bit, from a quick scan - given your usage of
> grub_json_parse in the luks2 module it appears that json_header (the
> underlying input string) will always outlive the json object.
>
> In which case, as there are no other existing users, we may want to make
> the API contract "The lifetime/validity of the returned object is bound
> by that of the input string", if we can comment/document that clearly
> then there is no need for this extra allocation and we can simply do:
>
> json->string = string;
>
>
> Thoughts?
Thing is that the parser needs to modify the string. This is kind
of an optimization in order to avoid the need for calling
`strdup` when returning a string, e.g. in `grub_json_getstring`.
We just modify the underlying string to have a '\0' in the right
place and then return it directly. It might feel weird to callers
that the parsed string is getting modified under their hands,
which is why I decided to just `strdup` it.
That being said, I don't have any hard feelings about this. I'm
fine with avoiding the `grub_strndup`, and if it's documented so
that callers know that it's getting modified then it should be
safe enough.
> > + if (!json->string)
> > + {
> > + err = GRUB_ERR_OUT_OF_MEMORY;
> > + goto out;
> > + }
> > +
> > + jsmn_init(&parser);
> > +
> > + while (1)
> > + {
> > + json->tokens = grub_realloc (json->tokens, sizeof (jsmntok_t) * ntokens);
>
> According to the docs, calling jsmn_parse with tokens = NULL will return
> the number of tokens required to properly parse the JSON, without trying
> to 'allocate' them in the token buffer (with the 'ntokens' parameter
> being ignored)
jsmn's examples curiously have the same realloc-loop that I do.
I'll check again and definitely convert to what you propose if
supported.
> > + if (!json->tokens)
> > + {
> > + err = GRUB_ERR_OUT_OF_MEMORY;
> > + goto out;
> > + }
> > +
> > + jsmn_err = jsmn_parse (&parser, string, string_len, json->tokens, ntokens);
> > + if (jsmn_err >= 0)
> > + break;
> > + if (jsmn_err != JSMN_ERROR_NOMEM)
> > + {
> > + err = GRUB_ERR_BAD_ARGUMENT;
> > + goto out;
> > + }
> > +
> > + ntokens <<= 1;
> > + }
> > +
> > + err = GRUB_ERR_NONE;
> > + *out = json;
> > +out:
> > + if (err && json)
> > + {
> > + grub_free (json->string);
> > + grub_free (json->tokens);
>
> Irrespective of the above - these two free's on
> json->string/json->tokens could be called on a NULL agrgment (e.g. if
> their initial allocation fails), I don't know whether it's common
> practice to allow grub_free (NULL), but I would encourage checking
> whether these are actually allocated before attempting to free them.
free(3P) explicitly mandates that it may be called with a `NULL`
pointer as argument, in which case it will just do nothing.
`grub_free` is in fact doing the same, so we should be good here.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-11-05 13:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-05 12:54 [PATCH v2 2/6] json: Implement wrapping interface Max Tottenham
2019-11-05 13:12 ` Patrick Steinhardt [this message]
2019-11-06 11:53 ` Daniel Kiper
2019-11-06 14:57 ` Max Tottenham
2019-11-06 20:20 ` Patrick Steinhardt
2019-11-07 2:51 ` Max Tottenham
2019-11-07 6:26 ` Patrick Steinhardt
2019-11-08 13:30 ` Max Tottenham
2019-11-10 16:44 ` Patrick Steinhardt
2019-11-13 11:43 ` Daniel Kiper
-- strict thread matches above, loose matches on Subject: below --
2019-11-02 18:06 [PATCH 0/6] Support for LUKS2 disc encryption Patrick Steinhardt
2019-11-05 6:58 ` [PATCH v2 0/6] Support for LUKS2 disk encryption Patrick Steinhardt
2019-11-05 6:58 ` [PATCH v2 2/6] json: Implement wrapping interface Patrick Steinhardt
2019-11-05 9:54 ` Max Tottenham
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=20191105131213.GA177916@ncase \
--to=ps@pks.im \
--cc=grub-devel@gnu.org \
--cc=mtottenh@akamai.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.