From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Wed, 8 Dec 2010 05:52:12 -0500 Subject: [U-Boot] [PATCH 3/5] Add hash table support as base for new environment code In-Reply-To: <20101208100238.EBA62140688@gemini.denx.de> References: <1279395948-25864-1-git-send-email-wd@denx.de> <201012080444.30675.vapier@gentoo.org> <20101208100238.EBA62140688@gemini.denx.de> Message-ID: <201012080552.12841.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wednesday, December 08, 2010 05:02:38 Wolfgang Denk wrote: > Mike Frysinger wrote: > > unless i'm missing something, the non-reentrant versions operate on a > > single shared hash table. so while this works today because there is > > only one > > Correct. > > > consumer (the env code), wont this cause problems as soon as someone else > > tries to use the non-reentrant hash table code ? as such, wouldnt it > > make sense to punt all of the non-reentrant versions and thus force > > everyone to maintain their own "struct hsearch_data" instance ? > > This could be done, but I don't see an immediate need. off the top of my head: - it isnt obvious to people today that this issue exists, so anyone attempting to use the fun new hashtable code could conceivably use it without running into a problem (as long as their keys dont happen to collide with env names). so people could possibly waste quite a bit of their time trying to track down bugs that only crop up when certain env vars are set. - i imagine a bit of space is being wasted here. - i re-implemented env-autocomplete, but i need access to the hashtable structure where everything is stored. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20101208/f9f23b19/attachment.pgp