From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1iSbFt-0003w3-SK for mharc-grub-devel@gnu.org; Thu, 07 Nov 2019 01:26:54 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36693) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSbFq-0003vn-D8 for grub-devel@gnu.org; Thu, 07 Nov 2019 01:26:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iSbFo-0002wp-MP for grub-devel@gnu.org; Thu, 07 Nov 2019 01:26:50 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:52777) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iSbFn-0002w1-V1 for grub-devel@gnu.org; Thu, 07 Nov 2019 01:26:48 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 31BBF21ADD; Thu, 7 Nov 2019 01:26:47 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 07 Nov 2019 01:26:47 -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=GSGCIkoFdaUcPVRd29SGn3BGil1 +yH8TzzJZvOuQY+8=; b=RQhEhWdB/BUVXQSdksjr+v45UobYhbJwgRThqGFiVcj lFuI8DIoHqVfwS8hQPUyljyVIdw2329s3ne5YvPWyvKUeXUM6KLaqt18G5yh4MOW Z991wpEBSCuV5WqT332+gd71WEPFxo2ThfgU7Olmsakf71vUH1Kc1Pln5Rd2b21D PwEEzJZazCJ4Pw/ALm3My09yjzR7AzyK7yg9NbUX1Mm/6N0Djr1xfdGewl9fXfFv zkLXiaPlt6HeKG4VeIq1NxWR3VRvKkcFaTwdu1Sfz61uSzy84+vtCUtD9DnibO3+ cwL6aoMBwUEimU4jgT1/8pEiHmunhn4C9FJQEL3SVZg== 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=GSGCIk oFdaUcPVRd29SGn3BGil1+yH8TzzJZvOuQY+8=; b=aXcxL1mfRn3t3bQgE8o/30 8eyeVlX+M2q0imhMh7M/nC+vTGDY/LFokooTc8iPpWKyzpLqowyu1AVpj1VOm7Kl fuE2zvMcW6T2kHT+/JHg1S9x58qVsWnJ2mOC3yxHq5gQC4aN7lj1spMrwmJTKU0E Wwx5JTTT8mV+LXLL/bzlsyPRWWh9TFevK9PgCPRCMspYJByRrukeKkqvpzz4lxEL ldLJOrH2/zDsdYOXMw94cfU6eF7sp3UbHKuVSx4OhVN/45al993cqPOLUQfOny/3 IA2RrOIyl99YrwJUhe1K6ts3912H2GBLXGpemV9ZAYDv3mX3xb86V5ntBWnPm3cA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddukedgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrrghtrhhi tghkucfuthgvihhnhhgrrhguthcuoehpshesphhkshdrihhmqeenucfkphepjeejrdduke efrdduiedvrdduvdenucfrrghrrghmpehmrghilhhfrhhomhepphhssehpkhhsrdhimhen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from NSJAIL (x4db7a20c.dyn.telefonica.de [77.183.162.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 644E93060057; Thu, 7 Nov 2019 01:26:45 -0500 (EST) Received: from localhost (10.192.0.11 [10.192.0.11]) by NSJAIL (OpenSMTPD) with ESMTPSA id 0fbb3eb2 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 7 Nov 2019 06:26:43 +0000 (UTC) Date: Thu, 7 Nov 2019 07:26:43 +0100 From: Patrick Steinhardt To: The development of GNU GRUB Cc: Max Tottenham , Daniel Kiper Subject: Re: [PATCH v2 2/6] json: Implement wrapping interface Message-ID: <20191107062643.GA2544@ncase> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <20191107025130.GA64831@lon-mpk47.lan> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.111.4.27 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: Thu, 07 Nov 2019 06:26:51 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 07, 2019 at 02:51:30AM +0000, Max Tottenham via Grub-devel wrot= e: > On 11/06, Patrick Steinhardt wrote: > > On Wed, Nov 06, 2019 at 02:57:52PM +0000, Max Tottenham wrote: > > > I had one more comment about this patch which I forgot to send > > > last time: > > >=20 > > > +struct grub_json > > > +{ > > > + void *tokens; > > > + char *string; > > > + grub_size_t idx; > > > +}; > > > +typedef struct grub_json grub_json_t; > > >=20 > > >=20 > > > Why is tokens declared as void* rather than jsmntok_t* ? There are a = bunch of > > > casts back to jsmntok_t * as part of your wrapper. > > >=20 > > > Is the idea to attempt to provide a separation between grub_json_* an= d jsmn (to > > > allow other libraries to implement the JSON module?). Or is there so= me sort of > > > pointer arithmetic I'm missing that requires the use of void*? > > >=20 > > > If it's the former, why don't we just do: > > >=20 > > > typedef jsmntok_t grub_json_tok_t; > > > struct grub_json > > > { > > > grub_json_tok_t *tokens; > > > char *string; > > > grub_size_t idx; > > > }; > > > typedef struct grub_json grub_json_t; > > >=20 > > >=20 > > > For now and worry about other libraries later? > >=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.h, > 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 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. Patrick --0F1p//8PRICkK4MW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEtmscHsieVjl9VyNUEXxntp6r8SwFAl3DuSEACgkQEXxntp6r 8SykCRAApH03bdmnnr05GMa+VIpYcjrenbVs3RVVeoHQI9E4irk4L8yrh917Vtdr ws3WEO3ziVwPSDSMFliM+p1RlSkl8TVf9dwVidlY4V253M9EECbjVWqYYgEQPPyr 2z19CEAzEl3RlgIJtjpAXl6Fb+VeW0tAzFfpXWV8m8IQQKZ32FCTLcbxcIdsKNF/ lQBbN4CmmplhQDvMjs0X9X1UbvAiKaBMul6eMXXWdFTo7H187+/6lr09TR3LpYYT Y6RlVLbFjjp9fJ1MonAGgXIU0vYoTLHDWsIjM7PctJjaIoItNO4DoGNi5/KI4bpY CW52cNUTCftON/JSgPLP13POr/+chLcGaK5KBS1ZJROtcwUKfNNyCmo/CJ5CE2kY NZg6SX1QZgflC49esqF4acDc6Gg9arJDRcCuUBEc1Q2a/xEpj6RSYMlcynr5G6hY l+lb+WM5KwKK6meU4jERzOnwxDdAeR47dEdlk8UsMA5u80vQvPknseBhky1sWF6I czYi5P5wPXHir1DSreHkjn2g8SZ2gf8+ZKFzMgAQYtCZTCT34gw3XRWFZuCXTB7f iP2vkWv+9eeiy1vPuR34E9XNA5eGlSMt5X5425C5HhS3S9ioRuPRGsHsM8cfvtmW 9zCziHBRZVYQCECs3t97bpaKW18XNyyHgqPOsxnBbIbq1obJnCw= =I8s8 -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW--