On Mon, Feb 26, 2024 at 03:55:10PM -0600, Nathan Bossart wrote:
> Committed.
I noticed that I forgot to update a couple of comments. While fixing
those, I discovered additional oversights that have been around since 2017.
I plan to commit this shortly.
--
Nathan Bossart
Amazon Web Services:
On Fri, Feb 23, 2024 at 03:52:16PM -0600, Nathan Bossart wrote:
> If there are no objections, I plan to commit these patches early next week.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sun, Jan 21, 2024 at 11:07:15PM -0600, Nathan Bossart wrote:
> I attempted to fix this in v2 of the patch set.
If there are no objections, I plan to commit these patches early next week.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sun, Jan 21, 2024 at 09:51:18PM -0600, Nathan Bossart wrote:
> I did notice a cfbot failure [0]. After a quick glance, I'm assuming this
> is caused by the memcpy() in insert_into_bucket(). Even if the string is
> short, it will copy the maximum key size, which is bad. So, 0002 is
> totally
On Mon, Jan 22, 2024 at 10:28:42AM +0800, Andy Fan wrote:
> Both LGTM.
Thanks for looking.
> +dshash_strcmp(const void *a, const void *b, size_t size, void *arg)
> +{
> + Assert(strlen((const char *) a) < size);
> + Assert(strlen((const char *) b) < size);
> +
>
> Do you think the below
Nathan Bossart writes:
> While working on the dynamic shared memory registry, I noticed a couple of
> potential improvements for code that uses dshash tables.
>
> * A couple of dshash_create() callers pass in 0 for the "void *arg"
> parameter, which seemed weird. I incorrectly assumed this
While working on the dynamic shared memory registry, I noticed a couple of
potential improvements for code that uses dshash tables.
* A couple of dshash_create() callers pass in 0 for the "void *arg"
parameter, which seemed weird. I incorrectly assumed this was some sort
of flags parameter
