From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from mail.smrk.net (mail.smrk.net [IPv6:2001:19f0:6c01:2788:5400:4ff:fe27:adaa]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 709331F452 for ; Wed, 30 Aug 2023 12:34:14 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=smrk.net header.i=@smrk.net header.a=rsa-sha256 header.s=20221002 header.b=Xv3URjgV; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smrk.net; s=20221002; t=1693398850; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wrS0gqs+nHk9RCReRPceIx7vBNJK2bLu4KgVJ4Iy3eA=; b=Xv3URjgVBLqeuPE4C4AV6xBqSssqTCXuPu0gb4LE0JlYhed1tN2stuiD+zR2CIYYiG8RWa SVXalsOdEcYYBLLCeYBJq2xN2Rk6hF2xd/yvvxJNexI9v0FhJIKfAQgezFGHV0zWS7dycv UsXYD2BbeGh1bCNEnQRU93Ydqb927IJJuhxWoHTO9dTqI42DEKe1mPwRn808EPRfjZyY7u zTF+9erYleBDZLHP3FYsTy30KphF8b21VVEITRwExhXWpqe0XhK/QRLm2d+Mm25jH3yXRd ShLNWkYoubSE9N5D8tfK+lxC7oagWApQf8A8tHT7CoMdF83F2e/4lP5V4MMLBQ== Received: from localhost ( [192.168.5.2]) by smrk (OpenSMTPD) with ESMTPSA id 7b98902e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 30 Aug 2023 14:34:10 +0200 (CEST) From: =?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?= To: Eric Wong Cc: meta@public-inbox.org Subject: Re: [PATCH 0/7] various build fixes + OpenBSD compat, [PATCH 7/7] xap_helper.h: fix double-free on OpenBSD hdestroy In-Reply-To: <20230830051045.330641-1-e@80x24.org> (Eric Wong's message of "Wed, 30 Aug 2023 05:10:38 +0000, Wed, 30 Aug 2023 05:10:45 +0000") References: <20230830051045.330641-1-e@80x24.org> <20230830051045.330641-1-e@80x24.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 30 Aug 2023 14:34:09 +0200 Message-ID: <20230830143409+0200.929541-stepnem@smrk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: On Wed, 30 Aug 2023 05:10:38 +0000 Eric Wong wrote: > 7/7 had me shaking my head for a bit, but I'd rather pay > that price than introduce weirdness with C++ templates. On Wed, 30 Aug 2023 05:10:45 +0000 Eric Wong wrote: > hdestroy on OpenBSD assumes each key in the table can be freed, > so use strdup to fulfil that requirement. > > This behavior differs from tested behavior on glibc and FreeBSD, > as well as what I can see from reading the musl and NetBSD > source code. OpenBSD may be the only relevant OS which requires > this workaround. I guess this won't help any, but it caught my attention and I've already done the digging, so I might as well share the findings: OpenBSD actually copied this behavior with the initial import (of hcreate.c) from NetBSD: $OpenBSD: hcreate.c,v 1.1 2004/06/24 04:43:33 millert Exp $ https://github.com/openbsd/src/commit/46f8fdc8de36 Commit: millert CommitDate: Thu Jun 24 04:43:33 2004 +0000 Working hcreate(3) et al from NetBSD (cgd) via ray at cyth dot net. Now passes the regress tests. NetBSD only changed the default to match FreeBSD in 2014, and also added hdestroy1 to allow caller control of element freeing: $NetBSD: hcreate.c,v 1.9 2014/07/20 13:34:17 christos Exp $ https://github.com/netbsd/src/commit/3b1b85d301bf6e608ce20b4152 Commit: christos CommitDate: Sun Jul 20 13:34:17 2014 +0000 Our hdestroy implementation was non-conformant because it freed the key of each entry. Add a new function hdestroy1 that allows the user to control what gets freed. Pointed out by Pedro Giffuni at FreeBSD. That said, I'm not sure what "non-conformant" in the NetBSD commit message refers to. POSIX doesn't say anything on the matter https://pubs.opengroup.org/onlinepubs/9699919799/functions/hcreate.html and there don't seem to be any other relevant standards. The NetBSD original (with the unconditional freeing) was apparently a from-scratch implementation from 2001: /* * hcreate() / hsearch() / hdestroy() * * SysV/XPG4 hash table functions. * * Implementation done based on NetBSD manual page and Solaris manual page, * plus my own personal experience about how they're supposed to work. * * I tried to look at Knuth (as cited by the Solaris manual page), but * nobody had a copy in the office, so... */ In any case, it does suck that OpenBSD is now the odd one out, but having no experience with the interface myself, I have no opinion on which behavior makes more sense. Thanks for working on these (though I've had no complaints regarding the actual functionality I need on OpenBSD so far) and let me know if you want me to test something. (With cindex.t out of the way (says 'ok' now, plus a few W: reaped unknown PID), "make test" now gets stuck on lei-import-http.t for me (with or without this series; still the same test instance); I haven't seen kqnotify.t fail in the few runs I did.) --=20 =C5=A0t=C4=9Bp=C3=A1n