From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1iTqKg-0004WQ-7K for mharc-grub-devel@gnu.org; Sun, 10 Nov 2019 11:44:58 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51937) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTqKd-0004WI-6v for grub-devel@gnu.org; Sun, 10 Nov 2019 11:44:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iTqKb-00053P-Uj for grub-devel@gnu.org; Sun, 10 Nov 2019 11:44:54 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:36791) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iTqKb-000529-DK for grub-devel@gnu.org; Sun, 10 Nov 2019 11:44:53 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2858321B03; Sun, 10 Nov 2019 11:44:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 10 Nov 2019 11:44:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pks.im; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=SRXVQmXW9HuGTwGxKuFj4dVtpvj 4rXxZahiTfOI23TQ=; b=lgqGyzdspYjtQfIpFUW+7H2zuSsQ7XcqY918hjA9IDb tW3e3WuuK8tX/iXgIK8uiWTWvyb6sd0Px9rVEqrHdlQmOOBzg2WiJXGJzraJOpCR CmyqmW01vfmziyvp7DF4lLd4vPzFf8LW6kKksIZB9s7/LK0NiWvihEpbC47Y9G6B 3Cmm0Zwz1Lwkt6NrySXQajHpxzDo437gvsaim57XCCRc+X4QXmFiGnHsuDlo/K4F wM3bDa22jo54SRb6AoBi6VMD5tLo93CYBOzQb63cXGKifFOBOM1JI2Za/vkUyCBY Xzp8nB9Q9CpTogmRf6d5E/2JKDgL43KpSBFwBp8n/7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=SRXVQm XW9HuGTwGxKuFj4dVtpvj4rXxZahiTfOI23TQ=; b=A2kjn7MiB2C5RXgZXcU0ey qvOIBGG8kvni6nXp2JNj1/e30996CVmhbfmuttcJUkKPa14kbae+4366A8cWATQW FIWNGDQf/F6oldtjwoTrUP2bJtkAXgYsVfwF31JgUkuBVdyr+DJtUEt5wde3gho7 Sd4YrtGmhx3aNJFNvJxdF+VezojO3lFJ/SEQY89VrOiUVK84Rk56B7XWGjBC1m9v gqc4LWyBG+EdifUNCYiywipjiBz1EkUNS3eu5jPdSB3kW+l7EOHltsLEipXZqyt2 Kqh25j6dQyLP/ias7sBcPKA1/RY+uNJELxIOinLvYfqBGYqzEN83wV6DlRgvNy/A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvhedgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrrghtrhhi tghkucfuthgvihhnhhgrrhguthcuoehpshesphhkshdrihhmqeenucfkphepjeekrdehhe drudeggedrvddvvdenucfrrghrrghmpehmrghilhhfrhhomhepphhssehpkhhsrdhimhen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from NSJAIL (x4e3790de.dyn.telefonica.de [78.55.144.222]) by mail.messagingengine.com (Postfix) with ESMTPA id 609C38005C; Sun, 10 Nov 2019 11:44:49 -0500 (EST) Received: from localhost ( [10.192.0.12]) by NSJAIL (OpenSMTPD) with ESMTPSA id 75e11ba6 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 10 Nov 2019 16:44:47 +0000 (UTC) Date: Sun, 10 Nov 2019 17:44:55 +0100 From: Patrick Steinhardt To: Max Tottenham Cc: The development of GNU GRUB , Daniel Kiper Subject: Re: [PATCH v2 2/6] json: Implement wrapping interface Message-ID: <20191110164455.GA17923@xps> References: <20191105125438.GA20442@lon-lp55b.london.corp.akamai.com> <20191105131213.GA177916@ncase> <20191106115319.wx2qowxk22xo4zot@tomti.i.net-space.pl> <20191106145752.GE20442@lon-lp55b.london.corp.akamai.com> <20191106202052.GA93095@ncase> <20191107025130.GA64831@lon-mpk47.lan> <20191107062643.GA2544@ncase> <20191108133028.GF20442@lon-lp55b.london.corp.akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <20191108133028.GF20442@lon-lp55b.london.corp.akamai.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.111.4.25 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 16:44:56 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 08, 2019 at 01:30:28PM +0000, Max Tottenham wrote: > On 11/07, Patrick Steinhardt wrote: > > On Thu, Nov 07, 2019 at 02:51:30AM +0000, Max Tottenham via Grub-devel = wrote: > > > On 11/06, Patrick Steinhardt wrote: > > > >=20 > > > > The reason is that we'd have to include "jsmn.h" in > > > > "include/grub/json.h" to make `jsmntok_t` available. I definitely > > > > want to avoid this in order to not leak any decls from jsmn into > > > > users of "json.h" and to be able to have "jsmn.h" live in > > > > "grub-core/lib/json". It's also not possible to have a forward > > > > declaration here due to how `jsmntok_t` is declared. > > > >=20 > > > > Patrick > > >=20 > > >=20 > > > In which case, looking again at this patchset - grub_json_t > > > is always used as an opaque value by consumers of json.h . > > >=20 > > > Why not put a forward declaration of grub_json_t in include/grub/json= =2Eh, > > > and stick the implementation in grub-core/lib/json.c : > > >=20 > > > include/grub/json.h: > > >=20 > > > typedef struct grub_json_t grub_json_t; > > > =20 > > > grub-core/lib/json.c: > > > ... > > > #include > > > #include "jsmn.h" > > > ... > > > struct grub_json_t { > > > jsmntok_t* tokens; > > > ... > > > }; > > >=20 > > >=20 > > > Unless there is something I'm missing doesn't the above achieve the > > > desired result?=20 > >=20 > > If we'd do that, all calls to `grub_json_get{child,value}` would > > have to return a dynamically allocated `grub_json_t` structure as > > the storage size of `grub_json_t` would not be known at compile > > time and thus cannot be allocated on the caller's stack. Right > > now, the caller can just declare the structure on-stack and have > > the interface fill up these structures for him, without any need > > for dynamic memory allocation. > >=20 > > Patrick >=20 > Ah, good point. I've been thinking about this for a while and I think > dealing with casts from void* really is the best we can do. >=20 > Perhaps jsmn upstream would accept a patch that does: >=20 > - typedef struct { > + typedef struct jsmntok_t { > ... > } jsmntok_t; >=20 > If they do we could revisit this later. I've created a pull request upstream to change exactly that -- let's wait and see. In the meantime we'll have to use the current `void *` workaround, but I'll make sure to update this as soon as the PR got merged (if ever). Patrick --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEtmscHsieVjl9VyNUEXxntp6r8SwFAl3IPoUACgkQEXxntp6r 8SwFgA//Yicnoxp12m/tLaMlcPnfHO/hX7ZtSvG058KKiqpNEH3X+aoc2odEbOdo h316npxuJx0a6ZD7rAzNelDqe6dbMMgiYVBuYIv3E/sedyV2myqu/5GXAH3q8nvO hXMNKSB7KmTBGpKmHeCO0AXS43e5uZA1mBeyNf2oSpN7Y2cyEJWajIqBmbmru+AC rq+UVcuFY+H9zBOwnzRWzE4WC50Nt6A/pZl+1s4/+BjD1XdD3PCo1AIHbyQobc4B JK0WJxyQoiQnpdlARKb9bHLZEiGF9JJ7E3jUgAhhrcO7xLoWyWmuWBfHrXrBDXM0 jE7/lq4X6BHGsOrIFBmixrdAPcicReyb1fWrdpOmxkl2ozSvQ51OVcRDzzubcvRZ jh0tn3/c4UHkO7LYIjlvj8XYVl1Sydz/aaQ7j/k0g/PlmRYG+WJ2y8rTXWVVNfvw gBo+dLU9oItvYNK1mhdDoZH8ksM+27dXvRpxxrOh+u58Rttlpf0u0Dod6c080045 5QM5dkoA1vlmT+iqzhMLlP7RMtVgLpzu8c2qY5PB08sfPVt+lrMu7iLjOddfKE86 /IA676+PsSZBB2qgv3wD0cSZQx6qMgpBcEs3g8b92NfZ5AYfp35Y0Vlju2uX3BZ/ R36rislQshN4Eitk54outzTbLW1bdyynhm6BSg4CXhh9N6kP/J4= =FT70 -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF--