Received: (at 77476-done) by debbugs.gnu.org; 20 Apr 2025 06:30:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 20 02:30:58 2025
Received: from localhost ([127.0.0.1]:43936 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u6OCf-0002ge-TS
for submit <at> debbugs.gnu.org; Sun, 20 Apr 2025 02:30:58 -0400
Received: from ns.weird.com ([198.96.117.51]:50432 helo=central.weird.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <woods@HIDDEN>) id 1u6OCc-0002gS-KB
for 77476-done <at> debbugs.gnu.org; Sun, 20 Apr 2025 02:30:55 -0400
Received: from (invalid client hostname: bind: DNS error: DNS lookup for A for
'more.local': Unknown host)more.local ((no PTR matching greeting
name)d207-216-250-146.bchsia.telus.net[207.216.250.146] port=58140)
by central.weird.com([198.96.117.51] port=587)
via TCP with esmtp (2796 bytes) (sender: <woods@HIDDEN>)
(ident <nobody> using UNIX) id <m1u6OCR-00rPJi0@HIDDEN>
for <77476-done <at> debbugs.gnu.org>;
Sun, 20 Apr 2025 02:30:43 -0400 (EDT)
(Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2022-Apr-6)
Received: from more.local ([10.0.1.129] port=58141)
by more.local([10.0.1.129] port=25) via TCP with esmtp (2315 bytes)
(sender: <woods@HIDDEN>) id <m1u6OCO-00Mo5f0@HIDDEN>
for <eliz@HIDDEN>; Sat, 19 Apr 2025 23:30:40 -0700 (PDT)
(Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2022-Apr-6)
Message-Id: <m1u6OCO-00Mo5f0@HIDDEN>
Date: Sat, 19 Apr 2025 23:30:39 -0700
From: "Greg A. Woods" <woods@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid
clashing with GnuTLS.
In-Reply-To: <b563004b-3d83-4bfd-a709-cecef6eb7624@HIDDEN>
References: <m1u0BWl-00NOtVC@HIDDEN> <86zfgxzuis.fsf@HIDDEN>
<m1u0QkE-00N3he0@HIDDEN> <864iz4yzt9.fsf@HIDDEN>
<86cyd88dm3.fsf@HIDDEN>
<b563004b-3d83-4bfd-a709-cecef6eb7624@HIDDEN>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0
Emacs/27.2 (x86_64-unknown-netbsd) MULE/6.0 (HANACHIRUSATO)
X-Face: ; j3Eth2XV8h1Yfu<eXd9JL+"t;
iT8?{X]Fjm`Qb]>*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][
lz; @-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\=<t0loVf0$}bP=]i3OMh"n_
_@m4/, ~2`V=(-9LyW.)'`@E_fE^<4y7)BIe`A''/j-Y#gDNZERh%CCij'q-NA4F<|yjznEhd7=l^xH
2.qD3o0IanGHERTW+z$G
Precedence: first-class
Organization: Robo-Hacker
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77476-done
Cc: Eli Zaretskii <eliz@HIDDEN>, 77476-done <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
At Sat, 19 Apr 2025 22:32:44 -0700, Paul Eggert <eggert@HIDDEN> wrote:
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.
>
> Hardly anybody links statically;
While this is probably true for Emacs, I find it is still good practice
to test that programs can still static-link. I also find that my
static-linked emacs will consistently start a good whole two seconds
faster on a much slower older system that the necessarily dynamic-linked
version starts on macOS on one of the newest and fastest of the x86
Mac-Pro systems, all other build options and runtime environment the same.
> Marking the bug as done.
Thanks! (and thanks also for prompting GnuTLS to fix the root problem)
--
Greg A. Woods <gwoods@HIDDEN>
Kelowna, BC +1 250 762-7675 RoboHack <woods@HIDDEN>
Planix, Inc. <woods@HIDDEN> Avoncote Farms <woods@HIDDEN>
"Greg A. Woods" <woods@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#77476; Package emacs.
Full text available.Received: (at 77476-done) by debbugs.gnu.org; 20 Apr 2025 05:32:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 20 01:32:55 2025 Received: from localhost ([127.0.0.1]:43260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u6NIU-0005Cz-EE for submit <at> debbugs.gnu.org; Sun, 20 Apr 2025 01:32:55 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:40090) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eggert@HIDDEN>) id 1u6NIR-0005Cf-1P for 77476-done <at> debbugs.gnu.org; Sun, 20 Apr 2025 01:32:52 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 0CC1A3C010841; Sat, 19 Apr 2025 22:32:45 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id xYJNdZXNQXjD; Sat, 19 Apr 2025 22:32:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id D7EBA3C010844; Sat, 19 Apr 2025 22:32:44 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu D7EBA3C010844 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1745127164; bh=yNQWYKeHqNn2DxvpFOfg6WjrxmqAa8RxJdcQ3ov5JpI=; h=Message-ID:Date:MIME-Version:To:From; b=D10MKCqowEp4VeYxMhPyc9UyXwIenbMqWdMSDVrSp0Mn88t2uD3HQ2TpNjb3Gw+eY n0M0Lm7mLhj0/ue2IMhvI/MuDHaG5b0yEu8NLmm5E2BV24MKZ7Mcgq5Nr0hErfXqSW 3sATw/393R0MCnQTY+aFRCBE2tmIJRraCe2gKL+3RsdKpV41+9+xCTQaBjRlsqZT1R QbHnuOTz5mi0W/1W+NVaSxOBVxSppyABT/IG4Nt/FD9SGSukznuUwm2KP7qmQ3NqWx wMgtAiqPfXBnRswOar/I+MU90urdcZPk1edfR47PHR7TqBqcE0JLHjV3jGjHMQshC/ sW7/lxN+Ogf9g== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id ANiLHB0d-OpV; Sat, 19 Apr 2025 22:32:44 -0700 (PDT) Received: from [192.168.254.12] (47-147-225-25.fdr01.snmn.ca.ip.frontiernet.net [47.147.225.25]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id B2FAA3C010841; Sat, 19 Apr 2025 22:32:44 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------WZZTtZ7Ua0Fg97WqUd6AGHCE" Message-ID: <b563004b-3d83-4bfd-a709-cecef6eb7624@HIDDEN> Date: Sat, 19 Apr 2025 22:32:44 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS. To: Eli Zaretskii <eliz@HIDDEN> References: <m1u0BWl-00NOtVC@HIDDEN> <86zfgxzuis.fsf@HIDDEN> <m1u0QkE-00N3he0@HIDDEN> <864iz4yzt9.fsf@HIDDEN> <86cyd88dm3.fsf@HIDDEN> Content-Language: en-US From: Paul Eggert <eggert@HIDDEN> Organization: UCLA Computer Science Department In-Reply-To: <86cyd88dm3.fsf@HIDDEN> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77476-done Cc: 77476-done <at> debbugs.gnu.org, woods@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------WZZTtZ7Ua0Fg97WqUd6AGHCE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2025-04-19 06:50, Eli Zaretskii wrote: > Paul, could you please chime in, since these are Gnulib > functions we're talking about. GnuTLS incorrectly exports some Gnulib functions to the outside world, and this breaks programs that use these function names for their own purposes. Gnulib has a way to fix this: its lib-symbol-visibility module. GnuTLS should use this (or do the equivalent by hand), but doesn't. I suppose GnuTLS has other visibility problems like this, and they should all be fixed. I filed a bug report with the GnuTLS folks about this; see <https://gitlab.com/gnutls/gnutls/-/issues/1703>. Possibly this problem even affects normal (i.e., dynamically linked) Emacs on some platforms. As Greg says, the semantics of name clashes is not portable, and I am particularly worried about what would happen if dynamically loaded modules refer to the clashing names on some random platform. As we can't expect GnuTLS to fix their bug soon, or for all our users to update to the fixed GnuTLS version soon, we should change the Emacs names to avoid the clash in the meantime. It's just two names so I did that, by installing the attached patch on master. I changed "hash_string" to "hash_char_array" which is a more accurate name as the argument is not a C string, and I changed "hash_lookup" to "hash_find" which is a bit shorter. I also changed two other names to match. I doubt whether this patch is urgent enough to backport to the emacs-30 branch. Hardly anybody links statically; the GnuTLS build procedure even warns against doing static linking (due to other static-linking problems that Emacs does not run into). And most likely, dynamically-linked modules won't use the clashing symbols. Marking the bug as done. --------------WZZTtZ7Ua0Fg97WqUd6AGHCE Content-Type: text/x-patch; charset=UTF-8; name="0001-Avoid-name-clashes-with-static-GnuTLS.patch" Content-Disposition: attachment; filename="0001-Avoid-name-clashes-with-static-GnuTLS.patch" Content-Transfer-Encoding: base64 RnJvbSBjOGVlZDkwZWI0ZDA1ODNkYzM0NjNlZGZhZDE3NmI5ZDNmOThkMTFmIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1 PgpEYXRlOiBTYXQsIDE5IEFwciAyMDI1IDE4OjQ0OjUyIC0wNzAwClN1YmplY3Q6IFtQQVRD SF0gQXZvaWQgbmFtZSBjbGFzaGVzIHdpdGggc3RhdGljIEdudVRMUwpNSU1FLVZlcnNpb246 IDEuMApDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1U cmFuc2Zlci1FbmNvZGluZzogOGJpdAoKV29yayBhcm91bmQgYSBidWcgaW4gR251VExTIDMu Ny4xMSBhbmQgZWFybGllcjogd2hlbiBidWlsdApzdGF0aWNhbGx5LCBpdHMgbWlzdGFrZW5s eSBleHBvcnRzIHN5bWJvbHMgaGFzaF9sb29rdXAgYW5kCmhhc2hfc3RyaW5nLCB3aGljaCBj b2xsaWRlIHdpdGggRW1hY3Mgc3ltYm9scyBvZiB0aGUgc2FtZSBuYW1lLApwcmV2ZW50aW5n IHRlbWFjcyBmcm9tIGxpbmtpbmcgc3RhdGljYWxseS4gIFByb2JsZW0gcmVwb3J0ZWQgYnkK R3JlZyBBLiBXb29kcyAoQnVnIzc3NDc2KS4KCkJlY2F1c2UgR251VExTIG5ldmVyIHVzZXMg aGFzaF9sb29rdXAgb3IgaGFzaF9zdHJpbmcgdGhpcyBpc3N1ZQpvcmRpbmFyaWx5IGRvZXNu 4oCZdCBzZWVtIHRvIHByZXZlbnQgdGVtYWNzIGZyb20gbGlua2luZyB0byBHbnVUTFMKb24g R05VL0xpbnV4LCBhcyBpdOKAmXMgbGlua2VkIGR5bmFtaWNhbGx5IGFuZCB0aGUgZHluYW1p YyBsaW5rZXIKbmV2ZXIgbmVlZHMgdG8gcmVzb2x2ZSByZWZlcmVuY2VzIHRvIGVpdGhlciBz eW1ib2wuICBIb3dldmVyLCBJCnN1cHBvc2UgYSBjbGFzaCBvciBidWcgY291bGQgb2NjdXIg ZXZlbiB3aXRoIGR5bmFtaWMgbGlua2luZyBpZgpFbWFjcyBsYXRlciBsb2FkcyBhIG1vZHVs ZSB0aGF0IHVzZXMgZWl0aGVyIHN5bWJvbC4KCkFsdGhvdWdoIEdudVRMUyBzaG91bGQgYmUg Zml4ZWQsIEVtYWNzIHNob3VsZCBsaW5rIHN0YXRpY2FsbHkgdG8KY3VycmVudCBhbmQgb2xk ZXIgR251VExTIHZlcnNpb25zIGluIHRoZSBtZWFudGltZSwgYW5kIGl0IHNob3VsZAphdm9p ZCBwb3RlbnRpYWwgcHJvYmxlbXMgd2l0aCBkeW5hbWljIGxpbmtpbmcuICBSZW5hbWluZyB0 aGUgdHdvCmNsYXNoaW5nIG5hbWVzIGlzIGFuIGVhc3kgd2F5IHRvIGRvIHRoaXMuICBGb3Ig Y29uc2lzdGVuY3kgd2l0aAp0aGUgbmV3IG5hbWUgZm9yIGhhc2hfbG9va3VwLCBhbHNvIHJl bmFtZSBoYXNoX2xvb2t1cF93aXRoX2hhc2gKYW5kIGhhc2hfbG9va3VwX2dldF9oYXNoLgoK KiBzcmMvZm5zLmMgKGhhc2hfZmluZF93aXRoX2hhc2gpOiBSZW5hbWUgZnJvbSBoYXNoX2xv b2t1cF93aXRoX2hhc2guCihoYXNoX2ZpbmQpOiBSZW5hbWUgZnJvbSBoYXNoX2xvb2t1cC4K KGhhc2hfZmluZF9nZXRfaGFzaCk6IFJlbmFtZSBmcm9tIGhhc2hfbG9va3VwX2dldF9oYXNo LgooaGFzaF9jaGFyX2FycmF5KTogUmVuYW1lIGZyb20gaGFzaF9zdHJpbmcuCkFsbCB1c2Vz IGNoYW5nZWQuCi0tLQogc3JjL2J5dGVjb2RlLmMgICAgIHwgIDIgKy0KIHNyYy9jYXRlZ29y eS5jICAgICB8ICAyICstCiBzcmMvY2NsLmMgICAgICAgICAgfCAgNCArKy0tCiBzcmMvY2hh cnNldC5jICAgICAgfCAgMyArLS0KIHNyYy9jaGFyc2V0LmggICAgICB8ICAyICstCiBzcmMv Y29kaW5nLmggICAgICAgfCAgMiArLQogc3JjL2NvbXBvc2l0ZS5jICAgIHwgIDIgKy0KIHNy Yy9lbWFjcy1tb2R1bGUuYyB8ICA2ICsrKy0tLQogc3JjL2Zucy5jICAgICAgICAgIHwgMjgg KysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLQogc3JjL2ltYWdlLmMgICAgICAgIHwgIDYg KysrLS0tCiBzcmMvanNvbi5jICAgICAgICAgfCAgMiArLQogc3JjL2xpc3AuaCAgICAgICAg IHwgIDggKysrKy0tLS0KIHNyYy9scmVhZC5jICAgICAgICB8IDE2ICsrKysrKysrLS0tLS0t LS0KIHNyYy9tYWNmb250Lm0gICAgICB8ICA0ICsrLS0KIHNyYy9taW5pYnVmLmMgICAgICB8 ICAyICstCiAxNSBmaWxlcyBjaGFuZ2VkLCA0NCBpbnNlcnRpb25zKCspLCA0NSBkZWxldGlv bnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvYnl0ZWNvZGUuYyBiL3NyYy9ieXRlY29kZS5jCmlu ZGV4IGVjZWEwYzZkZjM2Li40NDc1ZDRhMGIzMCAxMDA2NDQKLS0tIGEvc3JjL2J5dGVjb2Rl LmMKKysrIGIvc3JjL2J5dGVjb2RlLmMKQEAgLTE3NjMsNyArMTc2Myw3IEBAICNkZWZpbmUg REVGSU5FKG5hbWUsIHZhbHVlKSBbbmFtZV0gPSAmJmluc25fICMjIG5hbWUsCiAgICAgICAg ICAgICAgIH0KICAgICAgICAgICAgIGVsc2UKIAkgICAgICB7Ci0JCXB0cmRpZmZfdCBpID0g aGFzaF9sb29rdXAgKGgsIHYxKTsKKwkJcHRyZGlmZl90IGkgPSBoYXNoX2ZpbmQgKGgsIHYx KTsKIAkJaWYgKGkgPj0gMCkKIAkJICB7CiAJCSAgICBvcCA9IFhGSVhOVU0gKEhBU0hfVkFM VUUgKGgsIGkpKTsKZGlmZiAtLWdpdCBhL3NyYy9jYXRlZ29yeS5jIGIvc3JjL2NhdGVnb3J5 LmMKaW5kZXggMjk3YmE5NGM3M2QuLmY2NWM3ZDk0MzMxIDEwMDY0NAotLS0gYS9zcmMvY2F0 ZWdvcnkuYworKysgYi9zcmMvY2F0ZWdvcnkuYwpAQCAtNTQsNyArNTQsNyBAQCBoYXNoX2dl dF9jYXRlZ29yeV9zZXQgKExpc3BfT2JqZWN0IHRhYmxlLCBMaXNwX09iamVjdCBjYXRlZ29y eV9zZXQpCiAgICAgICAgbWFrZV9oYXNoX3RhYmxlICgmaGFzaHRlc3RfZXF1YWwsIERFRkFV TFRfSEFTSF9TSVpFLCBXZWFrX05vbmUpKTsKICAgc3RydWN0IExpc3BfSGFzaF9UYWJsZSAq aCA9IFhIQVNIX1RBQkxFIChYQ0hBUl9UQUJMRSAodGFibGUpLT5leHRyYXNbMV0pOwogICBo YXNoX2hhc2hfdCBoYXNoOwotICBwdHJkaWZmX3QgaSA9IGhhc2hfbG9va3VwX2dldF9oYXNo IChoLCBjYXRlZ29yeV9zZXQsICZoYXNoKTsKKyAgcHRyZGlmZl90IGkgPSBoYXNoX2ZpbmRf Z2V0X2hhc2ggKGgsIGNhdGVnb3J5X3NldCwgJmhhc2gpOwogICBpZiAoaSA+PSAwKQogICAg IHJldHVybiBIQVNIX0tFWSAoaCwgaSk7CiAgIGhhc2hfcHV0IChoLCBjYXRlZ29yeV9zZXQs IFFuaWwsIGhhc2gpOwpkaWZmIC0tZ2l0IGEvc3JjL2NjbC5jIGIvc3JjL2NjbC5jCmluZGV4 IGE0NWZlMDQzOWM0Li4zNjA5NGNhNjI3ZSAxMDA2NDQKLS0tIGEvc3JjL2NjbC5jCisrKyBi L3NyYy9jY2wuYwpAQCAtMTM3NSw3ICsxMzc1LDcgQEAgI2RlZmluZSBFWENNRCAoZmllbGQx ID4+IDYpCiAKIAkJZW9wID0gKEZJWE5VTV9PVkVSRkxPV19QIChyZWdbUlJSXSkKIAkJICAg ICAgID8gLTEKLQkJICAgICAgIDogaGFzaF9sb29rdXAgKGgsIG1ha2VfZml4bnVtIChyZWdb UlJSXSkpKTsKKwkJICAgICAgIDogaGFzaF9maW5kIChoLCBtYWtlX2ZpeG51bSAocmVnW1JS Ul0pKSk7CiAJCWlmIChlb3AgPj0gMCkKIAkJICB7CiAJCSAgICBMaXNwX09iamVjdCBvcGw7 CkBAIC0xNDA0LDcgKzE0MDQsNyBAQCAjZGVmaW5lIEVYQ01EIChmaWVsZDEgPj4gNikKIAog CQllb3AgPSAoRklYTlVNX09WRVJGTE9XX1AgKGkpCiAJCSAgICAgICA/IC0xCi0JCSAgICAg ICA6IGhhc2hfbG9va3VwIChoLCBtYWtlX2ZpeG51bSAoaSkpKTsKKwkJICAgICAgIDogaGFz aF9maW5kIChoLCBtYWtlX2ZpeG51bSAoaSkpKTsKIAkJaWYgKGVvcCA+PSAwKQogCQkgIHsK IAkJICAgIExpc3BfT2JqZWN0IG9wbDsKZGlmZiAtLWdpdCBhL3NyYy9jaGFyc2V0LmMgYi9z cmMvY2hhcnNldC5jCmluZGV4IDc5N2RmZGUyNzZmLi4zMjY0ZDc1ZjkyZSAxMDA2NDQKLS0t IGEvc3JjL2NoYXJzZXQuYworKysgYi9zcmMvY2hhcnNldC5jCkBAIC0xMTEyLDggKzExMTIs NyBAQCBERUZVTiAoImRlZmluZS1jaGFyc2V0LWludGVybmFsIiwgRmRlZmluZV9jaGFyc2V0 X2ludGVybmFsLAogCiAgIGhhc2hfaGFzaF90IGhhc2hfY29kZTsKICAgcHRyZGlmZl90IGhh c2hfaW5kZXgKLSAgICA9IGhhc2hfbG9va3VwX2dldF9oYXNoIChoYXNoX3RhYmxlLCBhcmdz W2NoYXJzZXRfYXJnX25hbWVdLAotCQkJICAgICZoYXNoX2NvZGUpOworICAgID0gaGFzaF9m aW5kX2dldF9oYXNoIChoYXNoX3RhYmxlLCBhcmdzW2NoYXJzZXRfYXJnX25hbWVdLCAmaGFz aF9jb2RlKTsKICAgaWYgKGhhc2hfaW5kZXggPj0gMCkKICAgICB7CiAgICAgICBuZXdfZGVm aW5pdGlvbl9wID0gZmFsc2U7CmRpZmYgLS1naXQgYS9zcmMvY2hhcnNldC5oIGIvc3JjL2No YXJzZXQuaAppbmRleCAwMjE3ZWMzMjFmZi4uZjc2ZTkxMDA4OTIgMTAwNjQ0Ci0tLSBhL3Ny Yy9jaGFyc2V0LmgKKysrIGIvc3JjL2NoYXJzZXQuaApAQCAtMjg1LDcgKzI4NSw3IEBAICNk ZWZpbmUgQ0hBUlNFVF9TWU1CT0xfSUQoc3ltYm9sKQlcCiAvKiBSZXR1cm4gYW4gaW5kZXgg dG8gVmNoYXJzZXRfaGFzaF90YWJsZSBvZiB0aGUgY2hhcnNldCB3aG9zZSBzeW1ib2wKICAg IGlzIFNZTUJPTC4gICovCiAjZGVmaW5lIENIQVJTRVRfU1lNQk9MX0hBU0hfSU5ERVgoc3lt Ym9sKQlcCi0gIGhhc2hfbG9va3VwIChYSEFTSF9UQUJMRSAoVmNoYXJzZXRfaGFzaF90YWJs ZSksIHN5bWJvbCkKKyAgaGFzaF9maW5kIChYSEFTSF9UQUJMRSAoVmNoYXJzZXRfaGFzaF90 YWJsZSksIHN5bWJvbCkKIAogLyogUmV0dXJuIHRoZSBhdHRyaWJ1dGUgdmVjdG9yIG9mIENI QVJTRVQuICAqLwogI2RlZmluZSBDSEFSU0VUX0FUVFJJQlVURVMoY2hhcnNldCkgKGNoYXJz ZXQpLT5hdHRyaWJ1dGVzCmRpZmYgLS1naXQgYS9zcmMvY29kaW5nLmggYi9zcmMvY29kaW5n LmgKaW5kZXggYjcyZmZkZTNjNTUuLjJkNTM4YmE2OWQzIDEwMDY0NAotLS0gYS9zcmMvY29k aW5nLmgKKysrIGIvc3JjL2NvZGluZy5oCkBAIC0xOTMsNyArMTkzLDcgQEAgI2RlZmluZSBD T0RJTkdfU1lTVEVNX1NQRUMoY29kaW5nX3N5c3RlbV9zeW1ib2wpCVwKIC8qIFJldHVybiB0 aGUgSUQgb2YgQ09ESU5HX1NZU1RFTV9TWU1CT0wuICAqLwogCiAjZGVmaW5lIENPRElOR19T WVNURU1fSUQoY29kaW5nX3N5c3RlbV9zeW1ib2wpCQkJXAotICBoYXNoX2xvb2t1cCAoWEhB U0hfVEFCTEUgKFZjb2Rpbmdfc3lzdGVtX2hhc2hfdGFibGUpLAkJXAorICBoYXNoX2ZpbmQg KFhIQVNIX1RBQkxFIChWY29kaW5nX3N5c3RlbV9oYXNoX3RhYmxlKSwJCVwKIAkgICAgICAg Y29kaW5nX3N5c3RlbV9zeW1ib2wpCiAKIC8qIFJldHVybiB0cnVlIGlmIENPRElOR19TWVNU RU1fU1lNQk9MIGlzIGEgY29kaW5nIHN5c3RlbS4gICovCmRpZmYgLS1naXQgYS9zcmMvY29t cG9zaXRlLmMgYi9zcmMvY29tcG9zaXRlLmMKaW5kZXggMmVmNzJhMzNkMmUuLmI2YzViNjFh NmE5IDEwMDY0NAotLS0gYS9zcmMvY29tcG9zaXRlLmMKKysrIGIvc3JjL2NvbXBvc2l0ZS5j CkBAIC0yNDEsNyArMjQxLDcgQEAgZ2V0X2NvbXBvc2l0aW9uX2lkIChwdHJkaWZmX3QgY2hh cnBvcywgcHRyZGlmZl90IGJ5dGVwb3MsIHB0cmRpZmZfdCBuY2hhcnMsCiAgICAgZ290byBp bnZhbGlkX2NvbXBvc2l0aW9uOwogCiAgIGhhc2hfaGFzaF90IGhhc2hfY29kZTsKLSAgaGFz aF9pbmRleCA9IGhhc2hfbG9va3VwX2dldF9oYXNoIChoYXNoX3RhYmxlLCBrZXksICZoYXNo X2NvZGUpOworICBoYXNoX2luZGV4ID0gaGFzaF9maW5kX2dldF9oYXNoIChoYXNoX3RhYmxl LCBrZXksICZoYXNoX2NvZGUpOwogICBpZiAoaGFzaF9pbmRleCA+PSAwKQogICAgIHsKICAg ICAgIC8qIFdlIGhhdmUgYWxyZWFkeSByZWdpc3RlcmVkIHRoZSBzYW1lIGNvbXBvc2l0aW9u LiAgQ2hhbmdlIFBST1AKZGlmZiAtLWdpdCBhL3NyYy9lbWFjcy1tb2R1bGUuYyBiL3NyYy9l bWFjcy1tb2R1bGUuYwppbmRleCA3Nzk3YjA0ZTAyNi4uMmZlY2E0MWU3YWUgMTAwNjQ0Ci0t LSBhL3NyYy9lbWFjcy1tb2R1bGUuYworKysgYi9zcmMvZW1hY3MtbW9kdWxlLmMKQEAgLTQx Myw3ICs0MTMsNyBAQCBYTU9EVUxFX0dMT0JBTF9SRUZFUkVOQ0UgKExpc3BfT2JqZWN0IG8p CiBtb2R1bGVfZ2xvYmFsX3JlZmVyZW5jZV9wIChlbWFjc192YWx1ZSB2LCBwdHJkaWZmX3Qg Km4pCiB7CiAgIHN0cnVjdCBMaXNwX0hhc2hfVGFibGUgKmggPSBYSEFTSF9UQUJMRSAoVm1v ZHVsZV9yZWZzX2hhc2gpOwotICAvKiBOb3RlIHRoYXQgd2UgY2FuJ3QgdXNlIGBoYXNoX2xv b2t1cCcgYmVjYXVzZSBWIG1pZ2h0IGJlIGEgbG9jYWwKKyAgLyogTm90ZSB0aGF0IHdlIGNh bid0IHVzZSBgaGFzaF9maW5kJyBiZWNhdXNlIFYgbWlnaHQgYmUgYSBsb2NhbAogICAgICBy ZWZlcmVuY2UgdGhhdCdzIGlkZW50aWNhbCB0byBzb21lIGdsb2JhbCByZWZlcmVuY2UuICAq LwogICBET0hBU0ggKGgsIGssIHZhbCkKICAgICBpZiAoJlhNT0RVTEVfR0xPQkFMX1JFRkVS RU5DRSAodmFsKS0+dmFsdWUgPT0gdikKQEAgLTQzMSw3ICs0MzEsNyBAQCBtb2R1bGVfbWFr ZV9nbG9iYWxfcmVmIChlbWFjc19lbnYgKmVudiwgZW1hY3NfdmFsdWUgdmFsdWUpCiAgIHN0 cnVjdCBMaXNwX0hhc2hfVGFibGUgKmggPSBYSEFTSF9UQUJMRSAoVm1vZHVsZV9yZWZzX2hh c2gpOwogICBMaXNwX09iamVjdCBuZXdfb2JqID0gdmFsdWVfdG9fbGlzcCAodmFsdWUpOwog ICBoYXNoX2hhc2hfdCBoYXNoY29kZTsKLSAgcHRyZGlmZl90IGkgPSBoYXNoX2xvb2t1cF9n ZXRfaGFzaCAoaCwgbmV3X29iaiwgJmhhc2hjb2RlKTsKKyAgcHRyZGlmZl90IGkgPSBoYXNo X2ZpbmRfZ2V0X2hhc2ggKGgsIG5ld19vYmosICZoYXNoY29kZSk7CiAKICAgLyogTm90ZTog VGhpcyBhcHByb2FjaCByZXF1aXJlcyB0aGUgZ2FyYmFnZSBjb2xsZWN0b3IgdG8gbmV2ZXIg bW92ZQogICAgICBvYmplY3RzLiAgKi8KQEAgLTQ3MCw3ICs0NzAsNyBAQCBtb2R1bGVfZnJl ZV9nbG9iYWxfcmVmIChlbWFjc19lbnYgKmVudiwgZW1hY3NfdmFsdWUgZ2xvYmFsX3ZhbHVl KQogICBNT0RVTEVfRlVOQ1RJT05fQkVHSU4gKCk7CiAgIHN0cnVjdCBMaXNwX0hhc2hfVGFi bGUgKmggPSBYSEFTSF9UQUJMRSAoVm1vZHVsZV9yZWZzX2hhc2gpOwogICBMaXNwX09iamVj dCBvYmogPSB2YWx1ZV90b19saXNwIChnbG9iYWxfdmFsdWUpOwotICBwdHJkaWZmX3QgaSA9 IGhhc2hfbG9va3VwIChoLCBvYmopOworICBwdHJkaWZmX3QgaSA9IGhhc2hfZmluZCAoaCwg b2JqKTsKIAogICBpZiAobW9kdWxlX2Fzc2VydGlvbnMpCiAgICAgewpkaWZmIC0tZ2l0IGEv c3JjL2Zucy5jIGIvc3JjL2Zucy5jCmluZGV4IGU5NjQzNjI3YmZhLi41MmY2NjdhNzJhNSAx MDA2NDQKLS0tIGEvc3JjL2Zucy5jCisrKyBiL3NyYy9mbnMuYwpAQCAtMjgxNSw4ICsyODE1 LDggQEAgZXF1YWxfbm9fcXVpdCAoTGlzcF9PYmplY3QgbzEsIExpc3BfT2JqZWN0IG8yKQog ICByZXR1cm4gaW50ZXJuYWxfZXF1YWwgKG8xLCBvMiwgRVFVQUxfTk9fUVVJVCwgMCwgUW5p bCk7CiB9CiAKLXN0YXRpYyBwdHJkaWZmX3QgaGFzaF9sb29rdXBfd2l0aF9oYXNoIChzdHJ1 Y3QgTGlzcF9IYXNoX1RhYmxlICpoLAotCQkJCQlMaXNwX09iamVjdCBrZXksIGhhc2hfaGFz aF90IGhhc2gpOworc3RhdGljIHB0cmRpZmZfdCBoYXNoX2ZpbmRfd2l0aF9oYXNoIChzdHJ1 Y3QgTGlzcF9IYXNoX1RhYmxlICpoLAorCQkJCSAgICAgIExpc3BfT2JqZWN0IGtleSwgaGFz aF9oYXNoX3QgaGFzaCk7CiAKIAogLyogUmV0dXJuIHRydWUgaWYgTzEgYW5kIE8yIGFyZSBl cXVhbC4gIEVRVUFMX0tJTkQgc3BlY2lmaWVzIHdoYXQga2luZApAQCAtMjg0OCw3ICsyODQ4 LDcgQEAgaW50ZXJuYWxfZXF1YWxfMSAoTGlzcF9PYmplY3QgbzEsIExpc3BfT2JqZWN0IG8y LCBlbnVtIGVxdWFsX2tpbmQgZXF1YWxfa2luZCwKIAkgIHsKIAkgICAgc3RydWN0IExpc3Bf SGFzaF9UYWJsZSAqaCA9IFhIQVNIX1RBQkxFICgqaHQpOwogCSAgICBoYXNoX2hhc2hfdCBo YXNoID0gaGFzaF9mcm9tX2tleSAoaCwgbzEpOwotCSAgICBwdHJkaWZmX3QgaSA9IGhhc2hf bG9va3VwX3dpdGhfaGFzaCAoaCwgbzEsIGhhc2gpOworCSAgICBwdHJkaWZmX3QgaSA9IGhh c2hfZmluZF93aXRoX2hhc2ggKGgsIG8xLCBoYXNoKTsKIAkgICAgaWYgKGkgPj0gMCkKIAkg ICAgICB7IC8qIGBvMScgd2FzIHNlZW4gYWxyZWFkeS4gICovCiAJCUxpc3BfT2JqZWN0IG8y cyA9IEhBU0hfVkFMVUUgKGgsIGkpOwpAQCAtNTAzMSw4ICs1MDMxLDggQEAgaGFzaF90YWJs ZV90aGF3IChMaXNwX09iamVjdCBoYXNoX3RhYmxlKQogLyogTG9vayB1cCBLRVkgd2l0aCBo YXNoIEhBU0ggaW4gdGFibGUgSC4KICAgIFJldHVybiBlbnRyeSBpbmRleCBvciAtMSBpZiBu b25lLiAgKi8KIHN0YXRpYyBwdHJkaWZmX3QKLWhhc2hfbG9va3VwX3dpdGhfaGFzaCAoc3Ry dWN0IExpc3BfSGFzaF9UYWJsZSAqaCwKLQkJICAgICAgIExpc3BfT2JqZWN0IGtleSwgaGFz aF9oYXNoX3QgaGFzaCkKK2hhc2hfZmluZF93aXRoX2hhc2ggKHN0cnVjdCBMaXNwX0hhc2hf VGFibGUgKmgsCisJCSAgICAgTGlzcF9PYmplY3Qga2V5LCBoYXNoX2hhc2hfdCBoYXNoKQog ewogICBwdHJkaWZmX3Qgc3RhcnRfb2ZfYnVja2V0ID0gaGFzaF9pbmRleF9pbmRleCAoaCwg aGFzaCk7CiAgIGZvciAocHRyZGlmZl90IGkgPSBIQVNIX0lOREVYIChoLCBzdGFydF9vZl9i dWNrZXQpOwpAQCAtNTA0OCwyMCArNTA0OCwyMCBAQCBoYXNoX2xvb2t1cF93aXRoX2hhc2gg KHN0cnVjdCBMaXNwX0hhc2hfVGFibGUgKmgsCiAKIC8qIExvb2sgdXAgS0VZIGluIHRhYmxl IEguICBSZXR1cm4gZW50cnkgaW5kZXggb3IgLTEgaWYgbm9uZS4gICovCiBwdHJkaWZmX3QK LWhhc2hfbG9va3VwIChzdHJ1Y3QgTGlzcF9IYXNoX1RhYmxlICpoLCBMaXNwX09iamVjdCBr ZXkpCitoYXNoX2ZpbmQgKHN0cnVjdCBMaXNwX0hhc2hfVGFibGUgKmgsIExpc3BfT2JqZWN0 IGtleSkKIHsKLSAgcmV0dXJuIGhhc2hfbG9va3VwX3dpdGhfaGFzaCAoaCwga2V5LCBoYXNo X2Zyb21fa2V5IChoLCBrZXkpKTsKKyAgcmV0dXJuIGhhc2hfZmluZF93aXRoX2hhc2ggKGgs IGtleSwgaGFzaF9mcm9tX2tleSAoaCwga2V5KSk7CiB9CiAKIC8qIExvb2sgdXAgS0VZIGlu IGhhc2ggdGFibGUgSC4gIFJldHVybiBpdHMgaGFzaCB2YWx1ZSBpbiAqUEhBU0guCiAgICBW YWx1ZSBpcyB0aGUgaW5kZXggb2YgdGhlIGVudHJ5IGluIEggbWF0Y2hpbmcgS0VZLCBvciAt MSBpZiBub3QgZm91bmQuICAqLwogcHRyZGlmZl90Ci1oYXNoX2xvb2t1cF9nZXRfaGFzaCAo c3RydWN0IExpc3BfSGFzaF9UYWJsZSAqaCwgTGlzcF9PYmplY3Qga2V5LAotCQkgICAgICBo YXNoX2hhc2hfdCAqcGhhc2gpCitoYXNoX2ZpbmRfZ2V0X2hhc2ggKHN0cnVjdCBMaXNwX0hh c2hfVGFibGUgKmgsIExpc3BfT2JqZWN0IGtleSwKKwkJICAgIGhhc2hfaGFzaF90ICpwaGFz aCkKIHsKICAgRU1BQ1NfVUlOVCBoYXNoID0gaGFzaF9mcm9tX2tleSAoaCwga2V5KTsKICAg KnBoYXNoID0gaGFzaDsKLSAgcmV0dXJuIGhhc2hfbG9va3VwX3dpdGhfaGFzaCAoaCwga2V5 LCBoYXNoKTsKKyAgcmV0dXJuIGhhc2hfZmluZF93aXRoX2hhc2ggKGgsIGtleSwgaGFzaCk7 CiB9CiAKIHN0YXRpYyB2b2lkCkBAIC01Mjg2LDcgKzUyODYsNyBAQCAjZGVmaW5lIFNYSEFT SF9NQVhfTEVOICAgNwogICAgY2FuIGJlIGFueSBFTUFDU19VSU5UIHZhbHVlLiAgKi8KIAog RU1BQ1NfVUlOVAotaGFzaF9zdHJpbmcgKGNoYXIgY29uc3QgKnB0ciwgcHRyZGlmZl90IGxl bikKK2hhc2hfY2hhcl9hcnJheSAoY2hhciBjb25zdCAqcHRyLCBwdHJkaWZmX3QgbGVuKQog ewogICBjaGFyIGNvbnN0ICpwICAgPSBwdHI7CiAgIGNoYXIgY29uc3QgKmVuZCA9IHB0ciAr IGxlbjsKQEAgLTU0NTksNyArNTQ1OSw3IEBAIHN4aGFzaF9vYmogKExpc3BfT2JqZWN0IG9i aiwgaW50IGRlcHRoKQogICAgICAgcmV0dXJuIFhIQVNIIChvYmopOwogCiAgICAgY2FzZSBM aXNwX1N0cmluZzoKLSAgICAgIHJldHVybiBoYXNoX3N0cmluZyAoU1NEQVRBIChvYmopLCBT QllURVMgKG9iaikpOworICAgICAgcmV0dXJuIGhhc2hfY2hhcl9hcnJheSAoU1NEQVRBIChv YmopLCBTQllURVMgKG9iaikpOwogCiAgICAgY2FzZSBMaXNwX1ZlY3Rvcmxpa2U6CiAgICAg ICB7CkBAIC01ODYxLDcgKzU4NjEsNyBAQCBERUZVTiAoImdldGhhc2giLCBGZ2V0aGFzaCwg U2dldGhhc2gsIDIsIDMsIDAsCiAgIChMaXNwX09iamVjdCBrZXksIExpc3BfT2JqZWN0IHRh YmxlLCBMaXNwX09iamVjdCBkZmx0KQogewogICBzdHJ1Y3QgTGlzcF9IYXNoX1RhYmxlICpo ID0gY2hlY2tfaGFzaF90YWJsZSAodGFibGUpOwotICBwdHJkaWZmX3QgaSA9IGhhc2hfbG9v a3VwIChoLCBrZXkpOworICBwdHJkaWZmX3QgaSA9IGhhc2hfZmluZCAoaCwga2V5KTsKICAg cmV0dXJuIGkgPj0gMCA/IEhBU0hfVkFMVUUgKGgsIGkpIDogZGZsdDsKIH0KIApAQCAtNTg3 Niw3ICs1ODc2LDcgQEAgREVGVU4gKCJwdXRoYXNoIiwgRnB1dGhhc2gsIFNwdXRoYXNoLCAz LCAzLCAwLAogICBjaGVja19tdXRhYmxlX2hhc2hfdGFibGUgKHRhYmxlLCBoKTsKIAogICBF TUFDU19VSU5UIGhhc2ggPSBoYXNoX2Zyb21fa2V5IChoLCBrZXkpOwotICBwdHJkaWZmX3Qg aSA9IGhhc2hfbG9va3VwX3dpdGhfaGFzaCAoaCwga2V5LCBoYXNoKTsKKyAgcHRyZGlmZl90 IGkgPSBoYXNoX2ZpbmRfd2l0aF9oYXNoIChoLCBrZXksIGhhc2gpOwogICBpZiAoaSA+PSAw KQogICAgIHNldF9oYXNoX3ZhbHVlX3Nsb3QgKGgsIGksIHZhbHVlKTsKICAgZWxzZQpkaWZm IC0tZ2l0IGEvc3JjL2ltYWdlLmMgYi9zcmMvaW1hZ2UuYwppbmRleCA2NWQ4ZGIyNGFkYy4u MWQzZmFlY2Y1MDcgMTAwNjQ0Ci0tLSBhL3NyYy9pbWFnZS5jCisrKyBiL3NyYy9pbWFnZS5j CkBAIC01NTUyLDcgKzU1NTIsNyBAQCB4cG1fZnJlZV9jb2xvcl9jYWNoZSAodm9pZCkKIHN0 YXRpYyBpbnQKIHhwbV9jb2xvcl9idWNrZXQgKGNoYXIgKmNvbG9yX25hbWUpCiB7Ci0gIEVN QUNTX1VJTlQgaGFzaCA9IGhhc2hfc3RyaW5nIChjb2xvcl9uYW1lLCBzdHJsZW4gKGNvbG9y X25hbWUpKTsKKyAgRU1BQ1NfVUlOVCBoYXNoID0gaGFzaF9jaGFyX2FycmF5IChjb2xvcl9u YW1lLCBzdHJsZW4gKGNvbG9yX25hbWUpKTsKICAgcmV0dXJuIGhhc2ggJSBYUE1fQ09MT1Jf Q0FDSEVfQlVDS0VUUzsKIH0KIApAQCAtNjIzOCw3ICs2MjM4LDcgQEAgeHBtX3B1dF9jb2xv cl90YWJsZV9oIChMaXNwX09iamVjdCBjb2xvcl90YWJsZSwKICAgTGlzcF9PYmplY3QgY2hh cnMgPSBtYWtlX3VuaWJ5dGVfc3RyaW5nIChjaGFyc19zdGFydCwgY2hhcnNfbGVuKTsKIAog ICBoYXNoX2hhc2hfdCBoYXNoX2NvZGU7Ci0gIGhhc2hfbG9va3VwX2dldF9oYXNoICh0YWJs ZSwgY2hhcnMsICZoYXNoX2NvZGUpOworICBoYXNoX2ZpbmRfZ2V0X2hhc2ggKHRhYmxlLCBj aGFycywgJmhhc2hfY29kZSk7CiAgIGhhc2hfcHV0ICh0YWJsZSwgY2hhcnMsIGNvbG9yLCBo YXNoX2NvZGUpOwogfQogCkBAIC02MjQ5LDcgKzYyNDksNyBAQCB4cG1fZ2V0X2NvbG9yX3Rh YmxlX2ggKExpc3BfT2JqZWN0IGNvbG9yX3RhYmxlLAogewogICBzdHJ1Y3QgTGlzcF9IYXNo X1RhYmxlICp0YWJsZSA9IFhIQVNIX1RBQkxFIChjb2xvcl90YWJsZSk7CiAgIHB0cmRpZmZf dCBpID0KLSAgICBoYXNoX2xvb2t1cCAodGFibGUsIG1ha2VfdW5pYnl0ZV9zdHJpbmcgKGNo YXJzX3N0YXJ0LCBjaGFyc19sZW4pKTsKKyAgICBoYXNoX2ZpbmQgKHRhYmxlLCBtYWtlX3Vu aWJ5dGVfc3RyaW5nIChjaGFyc19zdGFydCwgY2hhcnNfbGVuKSk7CiAKICAgcmV0dXJuIGkg Pj0gMCA/IEhBU0hfVkFMVUUgKHRhYmxlLCBpKSA6IFFuaWw7CiB9CmRpZmYgLS1naXQgYS9z cmMvanNvbi5jIGIvc3JjL2pzb24uYwppbmRleCA1Nzk1YzU4MmNlMC4uYmVhYzI0MmI3MDkg MTAwNjQ0Ci0tLSBhL3NyYy9qc29uLmMKKysrIGIvc3JjL2pzb24uYwpAQCAtMTU3MSw3ICsx NTcxLDcgQEAganNvbl9wYXJzZV9vYmplY3QgKHN0cnVjdCBqc29uX3BhcnNlciAqcGFyc2Vy KQogCSAgICBoYXNoX2hhc2hfdCBoYXNoOwogCSAgICBMaXNwX09iamVjdCBrZXkgPSBwYXJz ZXItPm9iamVjdF93b3Jrc3BhY2VbaV07CiAJICAgIExpc3BfT2JqZWN0IHZhbHVlID0gcGFy c2VyLT5vYmplY3Rfd29ya3NwYWNlW2kgKyAxXTsKLQkgICAgcHRyZGlmZl90IGkgPSBoYXNo X2xvb2t1cF9nZXRfaGFzaCAoaCwga2V5LCAmaGFzaCk7CisJICAgIHB0cmRpZmZfdCBpID0g aGFzaF9maW5kX2dldF9oYXNoIChoLCBrZXksICZoYXNoKTsKIAkgICAgaWYgKGkgPCAwKQog CSAgICAgIGhhc2hfcHV0IChoLCBrZXksIHZhbHVlLCBoYXNoKTsKIAkgICAgZWxzZQpkaWZm IC0tZ2l0IGEvc3JjL2xpc3AuaCBiL3NyYy9saXNwLmgKaW5kZXggYmNhNThiOWMxMmQuLmMy NDUwNDQwYWI5IDEwMDY0NAotLS0gYS9zcmMvbGlzcC5oCisrKyBiL3NyYy9saXNwLmgKQEAg LTQyNjEsMTQgKzQyNjEsMTQgQEAgI2RlZmluZSBDT05TX1RPX0lOVEVHRVIoY29ucywgdHlw ZSwgdmFyKQkJCQlcCiBleHRlcm4gYm9vbCBzd2VlcF93ZWFrX3RhYmxlIChzdHJ1Y3QgTGlz cF9IYXNoX1RhYmxlICosIGJvb2wpOwogZXh0ZXJuIHZvaWQgaGV4YnVmX2RpZ2VzdCAoY2hh ciAqLCB2b2lkIGNvbnN0ICosIGludCk7CiBleHRlcm4gY2hhciAqZXh0cmFjdF9kYXRhX2Zy b21fb2JqZWN0IChMaXNwX09iamVjdCwgcHRyZGlmZl90ICosIHB0cmRpZmZfdCAqKTsKLUVN QUNTX1VJTlQgaGFzaF9zdHJpbmcgKGNoYXIgY29uc3QgKiwgcHRyZGlmZl90KTsKK0VNQUNT X1VJTlQgaGFzaF9jaGFyX2FycmF5IChjaGFyIGNvbnN0ICosIHB0cmRpZmZfdCk7CiBFTUFD U19VSU5UIHN4aGFzaCAoTGlzcF9PYmplY3QpOwogTGlzcF9PYmplY3QgbWFrZV9oYXNoX3Rh YmxlIChjb25zdCBzdHJ1Y3QgaGFzaF90YWJsZV90ZXN0ICosIEVNQUNTX0lOVCwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaGFzaF90YWJsZV93ZWFrbmVzc190KTsKIExpc3Bf T2JqZWN0IGhhc2hfdGFibGVfd2Vha25lc3Nfc3ltYm9sIChoYXNoX3RhYmxlX3dlYWtuZXNz X3Qgd2Vhayk7Ci1wdHJkaWZmX3QgaGFzaF9sb29rdXAgKHN0cnVjdCBMaXNwX0hhc2hfVGFi bGUgKiwgTGlzcF9PYmplY3QpOwotcHRyZGlmZl90IGhhc2hfbG9va3VwX2dldF9oYXNoIChz dHJ1Y3QgTGlzcF9IYXNoX1RhYmxlICpoLCBMaXNwX09iamVjdCBrZXksCi0JCQkJaGFzaF9o YXNoX3QgKnBoYXNoKTsKK3B0cmRpZmZfdCBoYXNoX2ZpbmQgKHN0cnVjdCBMaXNwX0hhc2hf VGFibGUgKiwgTGlzcF9PYmplY3QpOworcHRyZGlmZl90IGhhc2hfZmluZF9nZXRfaGFzaCAo c3RydWN0IExpc3BfSGFzaF9UYWJsZSAqaCwgTGlzcF9PYmplY3Qga2V5LAorCQkJICAgICAg aGFzaF9oYXNoX3QgKnBoYXNoKTsKIHB0cmRpZmZfdCBoYXNoX3B1dCAoc3RydWN0IExpc3Bf SGFzaF9UYWJsZSAqLCBMaXNwX09iamVjdCwgTGlzcF9PYmplY3QsCiAJCSAgICBoYXNoX2hh c2hfdCk7CiB2b2lkIGhhc2hfcmVtb3ZlX2Zyb21fdGFibGUgKHN0cnVjdCBMaXNwX0hhc2hf VGFibGUgKiwgTGlzcF9PYmplY3QpOwpkaWZmIC0tZ2l0IGEvc3JjL2xyZWFkLmMgYi9zcmMv bHJlYWQuYwppbmRleCBkMzkzMzBiZDBlYi4uNWM4YmJlN2RhOWYgMTAwNjQ0Ci0tLSBhL3Ny Yy9scmVhZC5jCisrKyBiL3NyYy9scmVhZC5jCkBAIC00MjY2LDcgKzQyNjYsNyBAQCByZWFk MCAoTGlzcF9PYmplY3QgcmVhZGNoYXJmdW4sIGJvb2wgbG9jYXRlX3N5bXMpCiAJCQkgID0g WEhBU0hfVEFCTEUgKHJlYWRfb2JqZWN0c19tYXApOwogCQkJTGlzcF9PYmplY3QgbnVtYmVy ID0gbWFrZV9maXhudW0gKG4pOwogCQkJaGFzaF9oYXNoX3QgaGFzaDsKLQkJCXB0cmRpZmZf dCBpID0gaGFzaF9sb29rdXBfZ2V0X2hhc2ggKGgsIG51bWJlciwgJmhhc2gpOworCQkJcHRy ZGlmZl90IGkgPSBoYXNoX2ZpbmRfZ2V0X2hhc2ggKGgsIG51bWJlciwgJmhhc2gpOwogCQkJ aWYgKGkgPj0gMCkKIAkJCSAgLyogTm90IG5vcm1hbCwgYnV0IGlucHV0IGNvdWxkIGJlIG1h bGZvcm1lZC4gICovCiAJCQkgIHNldF9oYXNoX3ZhbHVlX3Nsb3QgKGgsIGksIHBsYWNlaG9s ZGVyKTsKQEAgLTQyODQsNyArNDI4NCw3IEBAIHJlYWQwIChMaXNwX09iamVjdCByZWFkY2hh cmZ1biwgYm9vbCBsb2NhdGVfc3ltcykKIAkJCS8qICNOIyAtLSByZWZlcmVuY2UgdG8gbnVt YmVyZWQgb2JqZWN0ICovCiAJCQlzdHJ1Y3QgTGlzcF9IYXNoX1RhYmxlICpoCiAJCQkgID0g WEhBU0hfVEFCTEUgKHJlYWRfb2JqZWN0c19tYXApOwotCQkJcHRyZGlmZl90IGkgPSBoYXNo X2xvb2t1cCAoaCwgbWFrZV9maXhudW0gKG4pKTsKKwkJCXB0cmRpZmZfdCBpID0gaGFzaF9m aW5kIChoLCBtYWtlX2ZpeG51bSAobikpOwogCQkJaWYgKGkgPCAwKQogCQkJICBJTlZBTElE X1NZTlRBWF9XSVRIX0JVRkZFUiAoKTsKIAkJCW9iaiA9IEhBU0hfVkFMVUUgKGgsIGkpOwpA QCAtNDU3OSw3ICs0NTc5LDcgQEAgcmVhZDAgKExpc3BfT2JqZWN0IHJlYWRjaGFyZnVuLCBi b29sIGxvY2F0ZV9zeW1zKQogCQlzdHJ1Y3QgTGlzcF9IYXNoX1RhYmxlICpoMgogCQkgID0g WEhBU0hfVEFCTEUgKHJlYWRfb2JqZWN0c19jb21wbGV0ZWQpOwogCQloYXNoX2hhc2hfdCBo YXNoOwotCQlwdHJkaWZmX3QgaSA9IGhhc2hfbG9va3VwX2dldF9oYXNoIChoMiwgcGxhY2Vo b2xkZXIsICZoYXNoKTsKKwkJcHRyZGlmZl90IGkgPSBoYXNoX2ZpbmRfZ2V0X2hhc2ggKGgy LCBwbGFjZWhvbGRlciwgJmhhc2gpOwogCQllYXNzZXJ0IChpIDwgMCk7CiAJCWhhc2hfcHV0 IChoMiwgcGxhY2Vob2xkZXIsIFFuaWwsIGhhc2gpOwogCQlvYmogPSBwbGFjZWhvbGRlcjsK QEAgLTQ1OTQsNyArNDU5NCw3IEBAIHJlYWQwIChMaXNwX09iamVjdCByZWFkY2hhcmZ1biwg Ym9vbCBsb2NhdGVfc3ltcykKIAkJICAgIHN0cnVjdCBMaXNwX0hhc2hfVGFibGUgKmgyCiAJ CSAgICAgID0gWEhBU0hfVEFCTEUgKHJlYWRfb2JqZWN0c19jb21wbGV0ZWQpOwogCQkgICAg aGFzaF9oYXNoX3QgaGFzaDsKLQkJICAgIHB0cmRpZmZfdCBpID0gaGFzaF9sb29rdXBfZ2V0 X2hhc2ggKGgyLCBvYmosICZoYXNoKTsKKwkJICAgIHB0cmRpZmZfdCBpID0gaGFzaF9maW5k X2dldF9oYXNoIChoMiwgb2JqLCAmaGFzaCk7CiAJCSAgICBlYXNzZXJ0IChpIDwgMCk7CiAJ CSAgICBoYXNoX3B1dCAoaDIsIG9iaiwgUW5pbCwgaGFzaCk7CiAJCSAgfQpAQCAtNDYwNiw4 ICs0NjA2LDggQEAgcmVhZDAgKExpc3BfT2JqZWN0IHJlYWRjaGFyZnVuLCBib29sIGxvY2F0 ZV9zeW1zKQogCQkvKiAuLi5hbmQgI24jIHdpbGwgdXNlIHRoZSByZWFsIHZhbHVlIGZyb20g bm93IG9uLiAgKi8KIAkJc3RydWN0IExpc3BfSGFzaF9UYWJsZSAqaCA9IFhIQVNIX1RBQkxF IChyZWFkX29iamVjdHNfbWFwKTsKIAkJaGFzaF9oYXNoX3QgaGFzaDsKLQkJcHRyZGlmZl90 IGkgPSBoYXNoX2xvb2t1cF9nZXRfaGFzaCAoaCwgZS0+dS5udW1iZXJlZC5udW1iZXIsCi0J CQkJCQkgICAgJmhhc2gpOworCQlwdHJkaWZmX3QgaSA9IGhhc2hfZmluZF9nZXRfaGFzaCAo aCwgZS0+dS5udW1iZXJlZC5udW1iZXIsCisJCQkJCQkgICZoYXNoKTsKIAkJZWFzc2VydCAo aSA+PSAwKTsKIAkJc2V0X2hhc2hfdmFsdWVfc2xvdCAoaCwgaSwgb2JqKTsKIAkgICAgICB9 CkBAIC00NjYxLDcgKzQ2NjEsNyBAQCBzdWJzdGl0dXRlX29iamVjdF9yZWN1cnNlIChzdHJ1 Y3Qgc3Vic3QgKnN1YnN0LCBMaXNwX09iamVjdCBzdWJ0cmVlKQogICAgICBieSAjbj0sIHdo aWNoIG1lYW5zIHRoYXQgd2UgY2FuIGZpbmQgaXQgYXMgYSB2YWx1ZSBpbgogICAgICBDT01Q TEVURUQuICAqLwogICBpZiAoRVEgKHN1YnN0LT5jb21wbGV0ZWQsIFF0KQotICAgICAgfHwg aGFzaF9sb29rdXAgKFhIQVNIX1RBQkxFIChzdWJzdC0+Y29tcGxldGVkKSwgc3VidHJlZSkg Pj0gMCkKKyAgICAgIHx8IGhhc2hfZmluZCAoWEhBU0hfVEFCTEUgKHN1YnN0LT5jb21wbGV0 ZWQpLCBzdWJ0cmVlKSA+PSAwKQogICAgIHN1YnN0LT5zZWVuID0gRmNvbnMgKHN1YnRyZWUs IHN1YnN0LT5zZWVuKTsKIAogICAvKiBSZWN1cnNlIGFjY29yZGluZyB0byBzdWJ0cmVlJ3Mg dHlwZS4KQEAgLTUxNzMsNyArNTE3Myw3IEBAIERFRlVOICgidW5pbnRlcm4iLCBGdW5pbnRl cm4sIFN1bmludGVybiwgMiwgMiwgMCwKIHN0YXRpYyBwdHJkaWZmX3QKIG9iYXJyYXlfaW5k ZXggKHN0cnVjdCBMaXNwX09iYXJyYXkgKm9hLCBjb25zdCBjaGFyICpzdHIsIHB0cmRpZmZf dCBzaXplX2J5dGUpCiB7Ci0gIEVNQUNTX1VJTlQgaGFzaCA9IGhhc2hfc3RyaW5nIChzdHIs IHNpemVfYnl0ZSk7CisgIEVNQUNTX1VJTlQgaGFzaCA9IGhhc2hfY2hhcl9hcnJheSAoc3Ry LCBzaXplX2J5dGUpOwogICByZXR1cm4ga251dGhfaGFzaCAocmVkdWNlX2VtYWNzX3VpbnRf dG9faGFzaF9oYXNoIChoYXNoKSwgb2EtPnNpemVfYml0cyk7CiB9CiAKZGlmZiAtLWdpdCBh L3NyYy9tYWNmb250Lm0gYi9zcmMvbWFjZm9udC5tCmluZGV4IDRmZjcyMGM1ZGQyLi4yYTBi OWFhMjU1NCAxMDA2NDQKLS0tIGEvc3JjL21hY2ZvbnQubQorKysgYi9zcmMvbWFjZm9udC5t CkBAIC0xMDE4LDcgKzEwMTgsNyBAQCBzdGF0aWMgdm9pZCBtYWNfZm9udF9nZXRfZ2x5cGhz X2Zvcl92YXJpYW50cyAoQ0ZEYXRhUmVmLCBVVEYzMkNoYXIsCiAgIGlmIChIQVNIX1RBQkxF X1AgKG1hY2ZvbnRfZmFtaWx5X2NhY2hlKSkKICAgICB7CiAgICAgICBzdHJ1Y3QgTGlzcF9I YXNoX1RhYmxlICpoID0gWEhBU0hfVEFCTEUgKG1hY2ZvbnRfZmFtaWx5X2NhY2hlKTsKLSAg ICAgIHB0cmRpZmZfdCBpID0gaGFzaF9sb29rdXAgKGgsIHN5bWJvbCk7CisgICAgICBwdHJk aWZmX3QgaSA9IGhhc2hfZmluZCAoaCwgc3ltYm9sKTsKIAogICAgICAgaWYgKGkgPj0gMCkK IAl7CkBAIC0xMDQ1LDcgKzEwNDUsNyBAQCBzdGF0aWMgdm9pZCBtYWNfZm9udF9nZXRfZ2x5 cGhzX2Zvcl92YXJpYW50cyAoQ0ZEYXRhUmVmLCBVVEYzMkNoYXIsCiAKICAgaCA9IFhIQVNI X1RBQkxFIChtYWNmb250X2ZhbWlseV9jYWNoZSk7CiAgIGhhc2hfaGFzaF90IGhhc2g7Ci0g IGkgPSBoYXNoX2xvb2t1cF9nZXRfaGFzaCAoaCwgc3ltYm9sLCAmaGFzaCk7CisgIGkgPSBo YXNoX2ZpbmRfZ2V0X2hhc2ggKGgsIHN5bWJvbCwgJmhhc2gpOwogICB2YWx1ZSA9IHN0cmlu ZyA/IG1ha2VfbWludF9wdHIgKCh2b2lkICopIENGUmV0YWluIChzdHJpbmcpKSA6IFFuaWw7 CiAgIGlmIChpID49IDApCiAgICAgewpkaWZmIC0tZ2l0IGEvc3JjL21pbmlidWYuYyBiL3Ny Yy9taW5pYnVmLmMKaW5kZXggMjhlYzc4MGIyNGUuLjZkOTYxNjBhODUxIDEwMDY0NAotLS0g YS9zcmMvbWluaWJ1Zi5jCisrKyBiL3NyYy9taW5pYnVmLmMKQEAgLTIxMDMsNyArMjEwMyw3 IEBAIERFRlVOICgidGVzdC1jb21wbGV0aW9uIiwgRnRlc3RfY29tcGxldGlvbiwgU3Rlc3Rf Y29tcGxldGlvbiwgMiwgMywgMCwKICAgZWxzZSBpZiAoSEFTSF9UQUJMRV9QIChjb2xsZWN0 aW9uKSkKICAgICB7CiAgICAgICBzdHJ1Y3QgTGlzcF9IYXNoX1RhYmxlICpoID0gWEhBU0hf VEFCTEUgKGNvbGxlY3Rpb24pOwotICAgICAgcHRyZGlmZl90IGkgPSBoYXNoX2xvb2t1cCAo aCwgc3RyaW5nKTsKKyAgICAgIHB0cmRpZmZfdCBpID0gaGFzaF9maW5kIChoLCBzdHJpbmcp OwogICAgICAgaWYgKGkgPj0gMCkKICAgICAgICAgewogICAgICAgICAgIHRlbSA9IEhBU0hf S0VZIChoLCBpKTsKLS0gCjIuNDguMQoK --------------WZZTtZ7Ua0Fg97WqUd6AGHCE--
"Greg A. Woods" <woods@HIDDEN>:Paul Eggert <eggert@HIDDEN>:Received: (at 77476) by debbugs.gnu.org; 19 Apr 2025 13:50:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 19 09:50:24 2025 Received: from localhost ([127.0.0.1]:60399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u68aO-0005E1-0z for submit <at> debbugs.gnu.org; Sat, 19 Apr 2025 09:50:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47780) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1u68aK-00059d-K3 for 77476 <at> debbugs.gnu.org; Sat, 19 Apr 2025 09:50:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1u68aE-0001af-7P; Sat, 19 Apr 2025 09:50:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=tPMuWtrmn2cRC/4s2oTkPhCgs2HsC0un8LXduGJvQyk=; b=l9hsSAxJfE+F HE8W3+iGRXvZUihGCfbA91MX4QM8SGKxcCj/pnFhnAIEckKrZKA7EM9hznQaqrbYHzWj4greXZMmp PGiUcMCzQjysdoJhPWkRlSW6G7K7eODQQ6+ORrGSxChLO1xdis7M3IsNAJWAHf9+n0/OxM+UXqMkp +J0fWN6VtpqrZyNjmuLQ27V2wK8J/u2d5ijpt2vh0sxwvRNgZecvoWTT+TA0zaHBa6oN/2+ZHw/vg zYUeTFAKehJg/X9lPo5pv/ClypwwXQQGkBf0sOo7zcsonrky/j3HmVOEVA1gEEXo7+j7mZoRY7YgV J3ccD61UrAQ1Ft+vs0OO1A==; Date: Sat, 19 Apr 2025 16:50:12 +0300 Message-Id: <86cyd88dm3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: eggert@HIDDEN In-Reply-To: <864iz4yzt9.fsf@HIDDEN> (message from Eli Zaretskii on Fri, 04 Apr 2025 13:40:50 +0300) Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS. References: <m1u0BWl-00NOtVC@HIDDEN> <86zfgxzuis.fsf@HIDDEN> <m1u0QkE-00N3he0@HIDDEN> <864iz4yzt9.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77476 Cc: 77476 <at> debbugs.gnu.org, woods@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Ping! Paul, could you please chime in, since these are Gnulib functions we're talking about. > Cc: 77476 <at> debbugs.gnu.org > Date: Fri, 04 Apr 2025 13:40:50 +0300 > From: Eli Zaretskii <eliz@HIDDEN> > > > Date: Thu, 03 Apr 2025 13:00:57 -0700 > > From: "Greg A. Woods" <woods@HIDDEN> > > Cc: 77476 <at> debbugs.gnu.org > > > > > > * src/fns.c: et al (hash_string, hash_lookup, hash_lookup_get_hash, > > > > hash_put, hash_remove_from_table): Rename with a leading "lisp_" prefix. > > > > > > Sorry, can you tell more about the rationale? Why do these clash? > > > > What do you mean by "Wny do these clash?"??? There are identical > > symbols in the GnuTLS library to some defined in Emacs, yet the > > implementations in each are entirely different and incompatible, and so > > they can't be static-linked into the same program. I.e. they "clash". > > > > The problematic symbols are actually from "imported" gnulib functions > > that are included in separate .o's in libgnutls.a, but since they are > > needed by other functions in libgnutls then they have to be loaded, but > > of course this is C and there are no namespaces (at least not without > > fudging it with global structures containing function pointers, or using > > the preprocessor and avoiding separate compilation, but GnuTLS clearly > > doesn't do either) to prevent them from clashing with already loaded > > functions from the application itself and the linker rightfully gives up > > and fails. > > > > There are only two (hash_lookup() and hash_string()) that actually > > clash, but it seems best to rename all the related global functions. > > I know the theory, but we are using GnuTLS with Emacs for many years, > so I wonder how come this never came up before. > > So I guess my question was why do they clash in your case, and why > didn't anyone complain until now? > > AFAICT, the functions hash_look up and hash_string are actually part > of Gnulib, and GnuTLS uses those Gnulib functions. Is that what you > see? > > > Static linking really should be mandated for all C programs, at least as > > a primary test, to be sure you always get what you think you're looking > > for and so that you really know the full extent of absolutely everything > > you're depending on. > > So this problem happens for you because you link Emacs statically with > GnuTLS? And if you use GnuTLS as a shared library, the problem > doesn't happen, is that right? > > > > Is this perhaps a matter of correct function visibility in a library? > > > > There's no such thing as "function visibility" in a plain old static C > > library. > > So this is again due to your use of static linking? > > > I don't know if this problem can affect dynamic-linked versions of Emacs > > or not, but presumably not or bugs would have shown up by now. I dunno > > -- the runtime dynamic linker is too much of a mysterious force to know > > for sure what it has done without dissecting exactly the result after > > the fact, and that's much harder to do as none of the implementations I > > know of have an option to produce a link map. > > Paul, what are your views on this issue, and WDYT we should do about > this? > > > In any case I think fixing the problems in GnuTLS is a far more > > extensive and complex job, and it's not even a tiny bit interesting to > > me as I have no vested interest in directly working on GnuTLS. My > > interest is far higher in Emacs! I would guess the whole method of > > importing gnulib functions would have to be changed in order to give > > those "private" (i.e. less-likely-to-ever-clash) names. > > > > I'm happy to use GnuTLS in Emacs if that's what Emacs developers would > > like to use, but I've also been relatively happy with using the tls > > package to access an external implementation as well (though it is > > tricky to maintain with constant changes in the command-lines and output > > formats). > > > > > Also, how come this comes up only now? > > > > I've been avoiding linking GnuTLS for quite some time, but with the tls > > package being deprecated for a while now (my primary production Emacs is > > now 27.2, tls.el moved to obsolete in 27.1) that's becoming a precarious > > position to take. > > Yes, but others are using GnuTLS since many Emacs 26, so any such > build problems should have been reported many years ago. > > > >
bug-gnu-emacs@HIDDEN:bug#77476; Package emacs.
Full text available.
Received: (at 77476) by debbugs.gnu.org; 4 Apr 2025 19:19:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 04 15:19:50 2025
Received: from localhost ([127.0.0.1]:40167 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u0mZx-0007UC-SG
for submit <at> debbugs.gnu.org; Fri, 04 Apr 2025 15:19:50 -0400
Received: from ns.weird.com ([198.96.117.51]:61614 helo=central.weird.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <woods@HIDDEN>) id 1u0mZu-0007Tu-5i
for 77476 <at> debbugs.gnu.org; Fri, 04 Apr 2025 15:19:47 -0400
Received: from (invalid client hostname: bind: DNS error: DNS lookup for A for
'more.local': Unknown host)more.local ((no PTR matching greeting
name)d207-216-250-146.bchsia.telus.net[207.216.250.146] port=54641)
by central.weird.com([198.96.117.51] port=587)
via TCP with esmtp (6875 bytes) (sender: <woods@HIDDEN>)
(ident <nobody> using UNIX) id <m1u0mZh-00rPQL0@HIDDEN>
for <77476 <at> debbugs.gnu.org>; Fri, 4 Apr 2025 15:19:33 -0400 (EDT)
(Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2022-Feb-11)
Received: from more.local ([10.0.1.129] port=54642)
by more.local([10.0.1.129] port=25) via TCP with esmtp (6386 bytes)
(sender: <woods@HIDDEN>) id <m1u0mZd-00NOtV0@HIDDEN>
for <77476 <at> debbugs.gnu.org>; Fri, 4 Apr 2025 12:19:29 -0700 (PDT)
(Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2022-Apr-6)
Message-Id: <m1u0mZd-00NOtV0@HIDDEN>
Date: Fri, 04 Apr 2025 12:19:29 -0700
From: "Greg A. Woods" <woods@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid
clashing with GnuTLS.
In-Reply-To: <864iz4yzt9.fsf@HIDDEN>
References: <m1u0BWl-00NOtVC@HIDDEN> <86zfgxzuis.fsf@HIDDEN>
<m1u0QkE-00N3he0@HIDDEN> <864iz4yzt9.fsf@HIDDEN>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0
Emacs/27.2 (x86_64-unknown-netbsd) MULE/6.0 (HANACHIRUSATO)
X-Face: ; j3Eth2XV8h1Yfu<eXd9JL+"t;
iT8?{X]Fjm`Qb]>*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][
lz; @-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\=<t0loVf0$}bP=]i3OMh"n_
_@m4/, ~2`V=(-9LyW.)'`@E_fE^<4y7)BIe`A''/j-Y#gDNZERh%CCij'q-NA4F<|yjznEhd7=l^xH
2.qD3o0IanGHERTW+z$G
Precedence: first-class
Organization: Robo-Hacker
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: multipart/signed;
boundary="pgp-sign-Multipart_Fri_Apr__4_12:19:17_2025-1"; micalg=pgp-sha1;
protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77476
Cc: 77476 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--pgp-sign-Multipart_Fri_Apr__4_12:19:17_2025-1
Content-Type: text/plain; charset=US-ASCII
At Fri, 04 Apr 2025 13:40:50 +0300, Eli Zaretskii <eliz@HIDDEN> wrote:
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.
>
> I know the theory, but we are using GnuTLS with Emacs for many years,
> so I wonder how come this never came up before.
Sorry, but apparently you don't know the _practice_. Theory is one
thing, but actually doing it in practical terms is necessary to fully
understand. It'll be a light-bulb moment, I promise. I don't mean to
be deprecating, but my initial thought on submitting this patch would be
that the problem was blindingly obvious and there would be no questions
whatsoever about the necessity of a fix -- just the colour of the bike
shed would need deciding.
> So I guess my question was why do they clash in your case, and why
> didn't anyone complain until now?
People have apparently forgotten about the benefits of static linking
and the necessity of testing it with C programs and so it rarely gets
done.
I have come up against this problem for several years -- I just didn't
bother fixing or reporting it because using lisp/tls.el was a sufficient
workaround. With tls.el moving to lisp/obsolete I've been prompted.
As I said, if one does not static-link a C program, at least as a test,
then one will not fully understand and appreciate all of the
dependencies and all of their interactions. This is a necessary caveat
due to the lack of namespaces in C.
> AFAICT, the functions hash_look up and hash_string are actually part
> of Gnulib, and GnuTLS uses those Gnulib functions. Is that what you
> see?
Indeed, that's what I reported, and what my submitted patch fixes, since
of course without my patch there are obviously also identically named
functions in Emacs. Here's proof of a sort that the patch works:
$ ll build-x86_64-nb9.99.81/src/emacs
276416 -rwxr-xr-x 2 woods wheel - 141404440 Apr 2 12:44 build-x86_64-nb9.99.81/src/emacs
$ size build-x86_64-nb9.99.81/src/emacs
text data bss dec hex filename
19149051 358196 2911673 22418920 15615e8 build-x86_64-nb9.99.81/src/emacs
$ file build-x86_64-nb9.99.81/src/emacs
build-x86_64-nb9.99.81/src/emacs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for NetBSD 9.99.81, with debug_info, not stripped
$ build-x86_64-nb9.99.81/src/emacs --version
GNU Emacs 31.0.50
Development version a72cfc52cc36 on master branch; build date 2025-04-02.
Copyright (C) 2025 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
$ build-x86_64-nb9.99.81/src/emacs --batch --eval '(if (gnutls-available-p) (message "has GnuTLS"))'
has GnuTLS
You can't have two different and incompatible implementations of a
function in the same C program when they both have the same identifier.
The runtime dynamic linker hides this problem from the average user and
papers over it hoping nothing goes wrong. Usually it works well enough
that nothing invokes undefined behaviour. I never bet on it being
correct though.
Maybe it would be a good idea for you to try static-linking Emacs.
> So this problem happens for you because you link Emacs statically with
> GnuTLS? And if you use GnuTLS as a shared library, the problem
> doesn't happen, is that right?
I would guess not, though that's based on my experience from a different
platform (macOS) where I have no problems dynamic-linking GnuTLS, but
that's not the platform where I always static-link things (NetBSD). So,
I don't really know -- I avoid shared libraries as much as possible, and
almost entirely on NetBSD always, but of course on macOS that's
impossible. However on macOS the entire object format is different and
the dynamic linker is also a completely unique implementation, so I
can's speak personally to the results with GNU ld(1) and NetBSD ld_elf.so.
> Yes, but others are using GnuTLS since many Emacs 26, so any such
> build problems should have been reported many years ago.
I doubt it. Most people don't even seem to know the difference between
static linking and dynamic runtime linking any more. They just type
"make".
--
Greg A. Woods <gwoods@HIDDEN>
Kelowna, BC +1 250 762-7675 RoboHack <woods@HIDDEN>
Planix, Inc. <woods@HIDDEN> Avoncote Farms <woods@HIDDEN>
--pgp-sign-Multipart_Fri_Apr__4_12:19:17_2025-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQTWEnAIIlcZX4oAawJie18UwlnHhQUCZ/AwuAAKCRBie18UwlnH
hQQvAKDkmmnZT7berrok7ILU2/9ks3kSuQCgwnQoG8fciN8tW124ZBVGFe6v+ck=
=4n3G
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Fri_Apr__4_12:19:17_2025-1--
"Greg A. Woods" <woods@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#77476; Package emacs.
Full text available.Received: (at 77476) by debbugs.gnu.org; 4 Apr 2025 10:41:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 04 06:41:03 2025 Received: from localhost ([127.0.0.1]:37180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u0eTu-0003DO-VH for submit <at> debbugs.gnu.org; Fri, 04 Apr 2025 06:41:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32838) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1u0eTs-0003CR-Cm for 77476 <at> debbugs.gnu.org; Fri, 04 Apr 2025 06:41:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1u0eTm-0005Hm-1y; Fri, 04 Apr 2025 06:40:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=GvBDe7gdGAx/VlOSL4i1WocK5Z0cXn24hWblyJ0S7UE=; b=B+e6T8X+vHFM wuEhVFvEl9woM4W/UgEB61P+6NKrgUqItKcp+eS3sLeOpbzIrOlw+JXn4tQYzJf2i3EJLDXvQPL09 Pch4Pg2X8SVfAedEO5okNFPgVxW1wysIft6YwCaKnMbz7Yucq/5G74RD/tV0abUWy3HMjLV/QtLLl wT/Le3/MCRpzPGTjP44+F4cgWl6zCBIRf/vHx2841n43gBOaVkc5ay+GqCT7RXop1EnfHcfzutiOF rcHzGIuCMM4sBg9nqIDHxazmMo2fvZgp/e/sFsDwejtY5K6pam+VdNWjbGwySLeUyD/OhSOngu1fB 1hA6qb0kkl4m9tIYQDiAQQ==; Date: Fri, 04 Apr 2025 13:40:50 +0300 Message-Id: <864iz4yzt9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: "Greg A. Woods" <woods@HIDDEN>, Paul Eggert <eggert@HIDDEN> In-Reply-To: <m1u0QkE-00N3he0@HIDDEN> (woods@HIDDEN) Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS. References: <m1u0BWl-00NOtVC@HIDDEN> <86zfgxzuis.fsf@HIDDEN> <m1u0QkE-00N3he0@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77476 Cc: 77476 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Thu, 03 Apr 2025 13:00:57 -0700 > From: "Greg A. Woods" <woods@HIDDEN> > Cc: 77476 <at> debbugs.gnu.org > > > > * src/fns.c: et al (hash_string, hash_lookup, hash_lookup_get_hash, > > > hash_put, hash_remove_from_table): Rename with a leading "lisp_" prefix. > > > > Sorry, can you tell more about the rationale? Why do these clash? > > What do you mean by "Wny do these clash?"??? There are identical > symbols in the GnuTLS library to some defined in Emacs, yet the > implementations in each are entirely different and incompatible, and so > they can't be static-linked into the same program. I.e. they "clash". > > The problematic symbols are actually from "imported" gnulib functions > that are included in separate .o's in libgnutls.a, but since they are > needed by other functions in libgnutls then they have to be loaded, but > of course this is C and there are no namespaces (at least not without > fudging it with global structures containing function pointers, or using > the preprocessor and avoiding separate compilation, but GnuTLS clearly > doesn't do either) to prevent them from clashing with already loaded > functions from the application itself and the linker rightfully gives up > and fails. > > There are only two (hash_lookup() and hash_string()) that actually > clash, but it seems best to rename all the related global functions. I know the theory, but we are using GnuTLS with Emacs for many years, so I wonder how come this never came up before. So I guess my question was why do they clash in your case, and why didn't anyone complain until now? AFAICT, the functions hash_look up and hash_string are actually part of Gnulib, and GnuTLS uses those Gnulib functions. Is that what you see? > Static linking really should be mandated for all C programs, at least as > a primary test, to be sure you always get what you think you're looking > for and so that you really know the full extent of absolutely everything > you're depending on. So this problem happens for you because you link Emacs statically with GnuTLS? And if you use GnuTLS as a shared library, the problem doesn't happen, is that right? > > Is this perhaps a matter of correct function visibility in a library? > > There's no such thing as "function visibility" in a plain old static C > library. So this is again due to your use of static linking? > I don't know if this problem can affect dynamic-linked versions of Emacs > or not, but presumably not or bugs would have shown up by now. I dunno > -- the runtime dynamic linker is too much of a mysterious force to know > for sure what it has done without dissecting exactly the result after > the fact, and that's much harder to do as none of the implementations I > know of have an option to produce a link map. Paul, what are your views on this issue, and WDYT we should do about this? > In any case I think fixing the problems in GnuTLS is a far more > extensive and complex job, and it's not even a tiny bit interesting to > me as I have no vested interest in directly working on GnuTLS. My > interest is far higher in Emacs! I would guess the whole method of > importing gnulib functions would have to be changed in order to give > those "private" (i.e. less-likely-to-ever-clash) names. > > I'm happy to use GnuTLS in Emacs if that's what Emacs developers would > like to use, but I've also been relatively happy with using the tls > package to access an external implementation as well (though it is > tricky to maintain with constant changes in the command-lines and output > formats). > > > Also, how come this comes up only now? > > I've been avoiding linking GnuTLS for quite some time, but with the tls > package being deprecated for a while now (my primary production Emacs is > now 27.2, tls.el moved to obsolete in 27.1) that's becoming a precarious > position to take. Yes, but others are using GnuTLS since many Emacs 26, so any such build problems should have been reported many years ago.
bug-gnu-emacs@HIDDEN:bug#77476; Package emacs.
Full text available.
Received: (at 77476) by debbugs.gnu.org; 3 Apr 2025 20:01:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 03 16:01:12 2025
Received: from localhost ([127.0.0.1]:35827 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u0QkS-0007AI-6u
for submit <at> debbugs.gnu.org; Thu, 03 Apr 2025 16:01:12 -0400
Received: from mail.robohack.planix.ca ([198.96.117.51]:51576
helo=central.weird.com) by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <woods@HIDDEN>) id 1u0QkP-0007A4-7Y
for 77476 <at> debbugs.gnu.org; Thu, 03 Apr 2025 16:01:10 -0400
Received: from (invalid client hostname: bind: DNS error: DNS lookup for A for
'more.local': Unknown host)more.local ((no PTR matching greeting
name)d207-216-250-146.bchsia.telus.net[207.216.250.146] port=60461)
by central.weird.com([198.96.117.51] port=587)
via TCP with esmtp (7060 bytes) (sender: <woods@HIDDEN>)
(ident <nobody> using UNIX) id <m1u0QkJ-00rPQL0@HIDDEN>
for <77476 <at> debbugs.gnu.org>; Thu, 3 Apr 2025 16:01:03 -0400 (EDT)
(Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2022-Feb-11)
Received: from more.local ([10.0.1.129] port=60462)
by more.local([10.0.1.129] port=25) via TCP with esmtp (6580 bytes)
(sender: <woods@HIDDEN>) id <m1u0QkE-00N3he0@HIDDEN>
for <eliz@HIDDEN>; Thu, 3 Apr 2025 13:00:58 -0700 (PDT)
(Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2022-Apr-6)
Message-Id: <m1u0QkE-00N3he0@HIDDEN>
Date: Thu, 03 Apr 2025 13:00:57 -0700
From: "Greg A. Woods" <woods@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid
clashing with GnuTLS.
In-Reply-To: <86zfgxzuis.fsf@HIDDEN>
References: <m1u0BWl-00NOtVC@HIDDEN>
<86zfgxzuis.fsf@HIDDEN>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0
Emacs/27.2 (x86_64-unknown-netbsd) MULE/6.0 (HANACHIRUSATO)
X-Face: ; j3Eth2XV8h1Yfu<eXd9JL+"t;
iT8?{X]Fjm`Qb]>*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][
lz; @-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\=<t0loVf0$}bP=]i3OMh"n_
_@m4/, ~2`V=(-9LyW.)'`@E_fE^<4y7)BIe`A''/j-Y#gDNZERh%CCij'q-NA4F<|yjznEhd7=l^xH
2.qD3o0IanGHERTW+z$G
Precedence: first-class
Organization: Robo-Hacker
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: multipart/signed;
boundary="pgp-sign-Multipart_Thu_Apr__3_13:00:38_2025-1"; micalg=pgp-sha1;
protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 77476
Cc: 77476 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--pgp-sign-Multipart_Thu_Apr__3_13:00:38_2025-1
Content-Type: text/plain; charset=US-ASCII
At Thu, 03 Apr 2025 08:25:15 +0300, Eli Zaretskii <eliz@HIDDEN> wrote:
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.
>
> > Date: Wed, 02 Apr 2025 20:46:03 -0700
> > From: "Greg A. Woods" <woods@HIDDEN>
> >
> > Rename various hash functions in src/fns.c to facilitate static-linking
> > with GnuTLS which includes clashing hash functions from its "gl"
> > subdirectory.
> >
> > * src/fns.c: et al (hash_string, hash_lookup, hash_lookup_get_hash,
> > hash_put, hash_remove_from_table): Rename with a leading "lisp_" prefix.
>
> Sorry, can you tell more about the rationale? Why do these clash?
What do you mean by "Wny do these clash?"??? There are identical
symbols in the GnuTLS library to some defined in Emacs, yet the
implementations in each are entirely different and incompatible, and so
they can't be static-linked into the same program. I.e. they "clash".
The problematic symbols are actually from "imported" gnulib functions
that are included in separate .o's in libgnutls.a, but since they are
needed by other functions in libgnutls then they have to be loaded, but
of course this is C and there are no namespaces (at least not without
fudging it with global structures containing function pointers, or using
the preprocessor and avoiding separate compilation, but GnuTLS clearly
doesn't do either) to prevent them from clashing with already loaded
functions from the application itself and the linker rightfully gives up
and fails.
There are only two (hash_lookup() and hash_string()) that actually
clash, but it seems best to rename all the related global functions.
Static linking really should be mandated for all C programs, at least as
a primary test, to be sure you always get what you think you're looking
for and so that you really know the full extent of absolutely everything
you're depending on. If you can't static-link a C program then there's
probably something fundamentally wrong with it's relationship to its
dependencies. C programmers need to remember they are writing C, not
Oberon-2 or Java or Go or some such other language with modules and
namespaces and such.
> Is this perhaps a matter of correct function visibility in a library?
There's no such thing as "function visibility" in a plain old static C
library. All global symbols are visible all the time, and depending on
internal dependencies of the object files you load, well you get what
you get from the rest of the library with no choice in how "visible" it
is to the rest of your binary. It's all "visible".
> And why does Emacs, and not GnuTLS, need to rename its functions?
The GnuTLS library is indeed somewhat of a mess in terms of the APIs it
presents, but since it's the "third party" here the choice is either to
kick it out, or to change the local definitions that clash.
I don't know if this problem can affect dynamic-linked versions of Emacs
or not, but presumably not or bugs would have shown up by now. I dunno
-- the runtime dynamic linker is too much of a mysterious force to know
for sure what it has done without dissecting exactly the result after
the fact, and that's much harder to do as none of the implementations I
know of have an option to produce a link map.
In any case I think fixing the problems in GnuTLS is a far more
extensive and complex job, and it's not even a tiny bit interesting to
me as I have no vested interest in directly working on GnuTLS. My
interest is far higher in Emacs! I would guess the whole method of
importing gnulib functions would have to be changed in order to give
those "private" (i.e. less-likely-to-ever-clash) names.
I'm happy to use GnuTLS in Emacs if that's what Emacs developers would
like to use, but I've also been relatively happy with using the tls
package to access an external implementation as well (though it is
tricky to maintain with constant changes in the command-lines and output
formats).
> Also, how come this comes up only now?
I've been avoiding linking GnuTLS for quite some time, but with the tls
package being deprecated for a while now (my primary production Emacs is
now 27.2, tls.el moved to obsolete in 27.1) that's becoming a precarious
position to take.
> In any case, the prefix "lisp_" doesn't sound right to me. Maybe
> "emacs_" or something similar, like just "e".
Meh -- potato po-ta-toe. I.e. I've no strong feelings about the
particular choice of prefix. You can choose whichever you like. I just
thought that since these functions are for accessing the "lisp hash
table", well they might best be named for it.
--
Greg A. Woods <gwoods@HIDDEN>
Kelowna, BC +1 250 762-7675 RoboHack <woods@HIDDEN>
Planix, Inc. <woods@HIDDEN> Avoncote Farms <woods@HIDDEN>
--pgp-sign-Multipart_Thu_Apr__3_13:00:38_2025-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQTWEnAIIlcZX4oAawJie18UwlnHhQUCZ+7o7wAKCRBie18UwlnH
hUVGAKDRa1U/4MSmAqHda32ID71NkLKupwCg2g9G9xvrEI+YFVhd9rYZHE4cNfc=
=gFsq
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Thu_Apr__3_13:00:38_2025-1--
"Greg A. Woods" <woods@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#77476; Package emacs.
Full text available.Received: (at 77476) by debbugs.gnu.org; 3 Apr 2025 05:25:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 03 01:25:30 2025 Received: from localhost ([127.0.0.1]:60447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1u0D50-0006WX-4G for submit <at> debbugs.gnu.org; Thu, 03 Apr 2025 01:25:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41488) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1u0D4x-0006WH-HF for 77476 <at> debbugs.gnu.org; Thu, 03 Apr 2025 01:25:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1u0D4p-0004Bp-GO; Thu, 03 Apr 2025 01:25:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Z4QXlJxP6v/O0Ty1J2j30TuLJtiIwtM947nzAqlJJwo=; b=TlLdfNEDDOLW HSM28uAbNVSrZSLLRIoQIzmw1I4yNR9qQxHALwR8VwfFtDZKESrYYNkeJBAPdKJENj4NsxWCNHhUm SNXvJz9727y+cPGsWX+c/G/SrIJcqbdcF2ATBiAYxEluU819LhEh09zw6ZBChzsyADhIW48L7bdKt rzeC2m0esJpQ0X0g2s/ELGMEXvdwq48G9y/nEIkzgx271wR00MTcWzJ5IPdNp8+YY+y2BWnOju8eM VHf+wf/CkQbCWS3xXZQM2T2SC2A9hdv90Kfr6PSIx8YtZGNgFZOTyNXh+EEcNurevxNuTqU966BYa AR9aQlYCuFBMbpEpnL7ILw==; Date: Thu, 03 Apr 2025 08:25:15 +0300 Message-Id: <86zfgxzuis.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: "Greg A. Woods" <woods@HIDDEN> In-Reply-To: <m1u0BWl-00NOtVC@HIDDEN> (woods@HIDDEN) Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS. References: <m1u0BWl-00NOtVC@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77476 Cc: 77476 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Wed, 02 Apr 2025 20:46:03 -0700 > From: "Greg A. Woods" <woods@HIDDEN> > > Rename various hash functions in src/fns.c to facilitate static-linking > with GnuTLS which includes clashing hash functions from its "gl" > subdirectory. > > * src/fns.c: et al (hash_string, hash_lookup, hash_lookup_get_hash, > hash_put, hash_remove_from_table): Rename with a leading "lisp_" prefix. Sorry, can you tell more about the rationale? Why do these clash? Is this perhaps a matter of correct function visibility in a library? And why does Emacs, and not GnuTLS, need to rename its functions? Also, how come this comes up only now? In any case, the prefix "lisp_" doesn't sound right to me. Maybe "emacs_" or something similar, like just "e".
bug-gnu-emacs@HIDDEN:bug#77476; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 3 Apr 2025 03:46:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 02 23:46:33 2025
Received: from localhost ([127.0.0.1]:60230 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u0BXD-0004Im-VV
for submit <at> debbugs.gnu.org; Wed, 02 Apr 2025 23:46:33 -0400
Received: from lists.gnu.org ([2001:470:142::17]:41448)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <woods@HIDDEN>)
id 1u0BXA-0004IY-Ap
for submit <at> debbugs.gnu.org; Wed, 02 Apr 2025 23:46:29 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <woods@HIDDEN>)
id 1u0BX4-0008C4-L4
for bug-gnu-emacs@HIDDEN; Wed, 02 Apr 2025 23:46:22 -0400
Received: from most.robohack.planix.com ([198.96.117.51]
helo=central.weird.com) by eggs.gnu.org with esmtp (Exim 4.90_1)
(envelope-from <woods@HIDDEN>) id 1u0BX1-0000k1-Mb
for bug-gnu-emacs@HIDDEN; Wed, 02 Apr 2025 23:46:22 -0400
Received: from (invalid client hostname: bind: DNS error: DNS lookup for A for
'more.local': Unknown host)more.local ((no PTR matching greeting
name)d207-216-250-146.bchsia.telus.net[207.216.250.146] port=64409)
by central.weird.com([198.96.117.51] port=587)
via TCP with esmtp (20486 bytes) (sender: <woods@HIDDEN>)
(ident <nobody> using UNIX) id <m1u0BWp-00rPQLC@HIDDEN>
for <bug-gnu-emacs@HIDDEN>; Wed, 2 Apr 2025 23:46:07 -0400 (EDT)
(Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2022-Feb-11)
Received: from more.local ([10.0.1.129] port=64410)
by more.local([10.0.1.129] port=25) via TCP with esmtp (19996 bytes)
(sender: <woods@HIDDEN>) id <m1u0BWl-00NOtVC@HIDDEN>
for <bug-gnu-emacs@HIDDEN>; Wed, 2 Apr 2025 20:46:03 -0700 (PDT)
(Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2022-Apr-6)
Message-Id: <m1u0BWl-00NOtVC@HIDDEN>
Date: Wed, 02 Apr 2025 20:46:03 -0700
From: "Greg A. Woods" <woods@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0
Emacs/27.2 (x86_64-unknown-netbsd) MULE/6.0 (HANACHIRUSATO)
X-Face: ; j3Eth2XV8h1Yfu<eXd9JL+"t;
iT8?{X]Fjm`Qb]>*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][
lz; @-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\=<t0loVf0$}bP=]i3OMh"n_
_@m4/, ~2`V=(-9LyW.)'`@E_fE^<4y7)BIe`A''/j-Y#gDNZERh%CCij'q-NA4F<|yjznEhd7=l^xH
2.qD3o0IanGHERTW+z$G
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: multipart/signed;
boundary="pgp-sign-Multipart_Wed_Apr__2_20:45:53_2025-1"; micalg=pgp-sha1;
protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=198.96.117.51; envelope-from=woods@HIDDEN;
helo=central.weird.com
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9,
HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
--pgp-sign-Multipart_Wed_Apr__2_20:45:53_2025-1
Content-Type: text/plain; charset=US-ASCII
Rename various hash functions in src/fns.c to facilitate static-linking
with GnuTLS which includes clashing hash functions from its "gl"
subdirectory.
* src/fns.c: et al (hash_string, hash_lookup, hash_lookup_get_hash,
hash_put, hash_remove_from_table): Rename with a leading "lisp_" prefix.
---
src/bytecode.c | 2 +-
src/category.c | 4 ++--
src/ccl.c | 4 ++--
src/charset.c | 4 ++--
src/charset.h | 2 +-
src/coding.h | 4 ++--
src/composite.c | 8 ++++----
src/emacs-module.c | 8 ++++----
src/fns.c | 24 ++++++++++++------------
src/image.c | 8 ++++----
src/json.c | 4 ++--
src/lisp.h | 14 +++++++-------
src/lread.c | 20 ++++++++++----------
src/minibuf.c | 2 +-
14 files changed, 54 insertions(+), 54 deletions(-)
diff --git a/src/bytecode.c b/src/bytecode.c
index ecea0c6df36..9d4f9de3eb4 100644
--- a/src/bytecode.c
+++ b/src/bytecode.c
@@ -1763,7 +1763,7 @@ #define DEFINE(name, value) [name] = &&insn_ ## name,
}
else
{
- ptrdiff_t i = hash_lookup (h, v1);
+ ptrdiff_t i = lisp_hash_lookup (h, v1);
if (i >= 0)
{
op = XFIXNUM (HASH_VALUE (h, i));
diff --git a/src/category.c b/src/category.c
index 297ba94c73d..9909ba5701c 100644
--- a/src/category.c
+++ b/src/category.c
@@ -54,10 +54,10 @@ hash_get_category_set (Lisp_Object table, Lisp_Object category_set)
make_hash_table (&hashtest_equal, DEFAULT_HASH_SIZE, Weak_None));
struct Lisp_Hash_Table *h = XHASH_TABLE (XCHAR_TABLE (table)->extras[1]);
hash_hash_t hash;
- ptrdiff_t i = hash_lookup_get_hash (h, category_set, &hash);
+ ptrdiff_t i = lisp_hash_lookup_get_hash (h, category_set, &hash);
if (i >= 0)
return HASH_KEY (h, i);
- hash_put (h, category_set, Qnil, hash);
+ lisp_hash_put (h, category_set, Qnil, hash);
return category_set;
}
diff --git a/src/ccl.c b/src/ccl.c
index a45fe0439c4..dfb50be71ac 100644
--- a/src/ccl.c
+++ b/src/ccl.c
@@ -1375,7 +1375,7 @@ #define EXCMD (field1 >> 6)
eop = (FIXNUM_OVERFLOW_P (reg[RRR])
? -1
- : hash_lookup (h, make_fixnum (reg[RRR])));
+ : lisp_hash_lookup (h, make_fixnum (reg[RRR])));
if (eop >= 0)
{
Lisp_Object opl;
@@ -1404,7 +1404,7 @@ #define EXCMD (field1 >> 6)
eop = (FIXNUM_OVERFLOW_P (i)
? -1
- : hash_lookup (h, make_fixnum (i)));
+ : lisp_hash_lookup (h, make_fixnum (i)));
if (eop >= 0)
{
Lisp_Object opl;
diff --git a/src/charset.c b/src/charset.c
index 797dfde276f..d66476a79b9 100644
--- a/src/charset.c
+++ b/src/charset.c
@@ -1112,7 +1112,7 @@ DEFUN ("define-charset-internal", Fdefine_charset_internal,
hash_hash_t hash_code;
ptrdiff_t hash_index
- = hash_lookup_get_hash (hash_table, args[charset_arg_name],
+ = lisp_hash_lookup_get_hash (hash_table, args[charset_arg_name],
&hash_code);
if (hash_index >= 0)
{
@@ -1122,7 +1122,7 @@ DEFUN ("define-charset-internal", Fdefine_charset_internal,
}
else
{
- hash_put (hash_table, args[charset_arg_name], attrs, hash_code);
+ lisp_hash_put (hash_table, args[charset_arg_name], attrs, hash_code);
if (charset_table_used == charset_table_size)
{
/* Ensure that charset IDs fit into 'int' as well as into the
diff --git a/src/charset.h b/src/charset.h
index 0217ec321ff..def4d13180d 100644
--- a/src/charset.h
+++ b/src/charset.h
@@ -285,7 +285,7 @@ #define CHARSET_SYMBOL_ID(symbol) \
/* Return an index to Vcharset_hash_table of the charset whose symbol
is SYMBOL. */
#define CHARSET_SYMBOL_HASH_INDEX(symbol) \
- hash_lookup (XHASH_TABLE (Vcharset_hash_table), symbol)
+ lisp_hash_lookup (XHASH_TABLE (Vcharset_hash_table), symbol)
/* Return the attribute vector of CHARSET. */
#define CHARSET_ATTRIBUTES(charset) (charset)->attributes
diff --git a/src/coding.h b/src/coding.h
index b72ffde3c55..73c3aa3bfc2 100644
--- a/src/coding.h
+++ b/src/coding.h
@@ -193,8 +193,8 @@ #define CODING_SYSTEM_SPEC(coding_system_symbol) \
/* Return the ID of CODING_SYSTEM_SYMBOL. */
#define CODING_SYSTEM_ID(coding_system_symbol) \
- hash_lookup (XHASH_TABLE (Vcoding_system_hash_table), \
- coding_system_symbol)
+ lisp_hash_lookup (XHASH_TABLE (Vcoding_system_hash_table), \
+ coding_system_symbol)
/* Return true if CODING_SYSTEM_SYMBOL is a coding system. */
diff --git a/src/composite.c b/src/composite.c
index 2ef72a33d2e..9f6554fa74a 100644
--- a/src/composite.c
+++ b/src/composite.c
@@ -241,7 +241,7 @@ get_composition_id (ptrdiff_t charpos, ptrdiff_t bytepos, ptrdiff_t nchars,
goto invalid_composition;
hash_hash_t hash_code;
- hash_index = hash_lookup_get_hash (hash_table, key, &hash_code);
+ hash_index = lisp_hash_lookup_get_hash (hash_table, key, &hash_code);
if (hash_index >= 0)
{
/* We have already registered the same composition. Change PROP
@@ -302,7 +302,7 @@ get_composition_id (ptrdiff_t charpos, ptrdiff_t bytepos, ptrdiff_t nchars,
XSETCDR (prop, Fcons (make_fixnum (nchars), Fcons (key, XCDR (prop))));
/* Register the composition in composition_hash_table. */
- hash_index = hash_put (hash_table, key, id, hash_code);
+ hash_index = lisp_hash_put (hash_table, key, id, hash_code);
method = (NILP (components)
? COMPOSITION_RELATIVE
@@ -664,7 +664,7 @@ composition_gstring_put_cache (Lisp_Object gstring, ptrdiff_t len)
LGSTRING_SET_HEADER (copy, Fcopy_sequence (header));
for (ptrdiff_t i = 0; i < len; i++)
LGSTRING_SET_GLYPH (copy, i, Fcopy_sequence (LGSTRING_GLYPH (gstring, i)));
- ptrdiff_t id = hash_put (h, LGSTRING_HEADER (copy), copy, hash);
+ ptrdiff_t id = lisp_hash_put (h, LGSTRING_HEADER (copy), copy, hash);
LGSTRING_SET_ID (copy, make_fixnum (id));
return copy;
}
@@ -686,7 +686,7 @@ composition_gstring_cache_clear_font (Lisp_Object font_object)
DOHASH (h, k, gstring)
if (EQ (LGSTRING_FONT (gstring), font_object))
- hash_remove_from_table (h, k);
+ lisp_hash_remove_from_table (h, k);
}
DEFUN ("clear-composition-cache", Fclear_composition_cache,
diff --git a/src/emacs-module.c b/src/emacs-module.c
index 7797b04e026..b535aff5fcd 100644
--- a/src/emacs-module.c
+++ b/src/emacs-module.c
@@ -431,7 +431,7 @@ module_make_global_ref (emacs_env *env, emacs_value value)
struct Lisp_Hash_Table *h = XHASH_TABLE (Vmodule_refs_hash);
Lisp_Object new_obj = value_to_lisp (value);
hash_hash_t hashcode;
- ptrdiff_t i = hash_lookup_get_hash (h, new_obj, &hashcode);
+ ptrdiff_t i = lisp_hash_lookup_get_hash (h, new_obj, &hashcode);
/* Note: This approach requires the garbage collector to never move
objects. */
@@ -455,7 +455,7 @@ module_make_global_ref (emacs_env *env, emacs_value value)
ref->refcount = 1;
Lisp_Object value;
XSETPSEUDOVECTOR (value, ref, PVEC_OTHER);
- hash_put (h, new_obj, value, hashcode);
+ lisp_hash_put (h, new_obj, value, hashcode);
MODULE_INTERNAL_CLEANUP ();
return &ref->value;
}
@@ -470,7 +470,7 @@ module_free_global_ref (emacs_env *env, emacs_value global_value)
MODULE_FUNCTION_BEGIN ();
struct Lisp_Hash_Table *h = XHASH_TABLE (Vmodule_refs_hash);
Lisp_Object obj = value_to_lisp (global_value);
- ptrdiff_t i = hash_lookup (h, obj);
+ ptrdiff_t i = lisp_hash_lookup (h, obj);
if (module_assertions)
{
@@ -486,7 +486,7 @@ module_free_global_ref (emacs_env *env, emacs_value global_value)
struct module_global_reference *ref = XMODULE_GLOBAL_REFERENCE (value);
eassert (0 < ref->refcount);
if (--ref->refcount == 0)
- hash_remove_from_table (h, obj);
+ lisp_hash_remove_from_table (h, obj);
}
MODULE_INTERNAL_CLEANUP ();
diff --git a/src/fns.c b/src/fns.c
index 3f109a81836..c1572d11ea9 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -2858,7 +2858,7 @@ internal_equal_1 (Lisp_Object o1, Lisp_Object o2, enum equal_kind equal_kind,
set_hash_value_slot (h, i, Fcons (o2, o2s));
}
else
- hash_put (h, o1, Fcons (o2, Qnil), hash);
+ lisp_hash_put (h, o1, Fcons (o2, Qnil), hash);
}
default: ;
}
@@ -5050,7 +5050,7 @@ hash_lookup_with_hash (struct Lisp_Hash_Table *h,
/* Look up KEY in table H. Return entry index or -1 if none. */
ptrdiff_t
-hash_lookup (struct Lisp_Hash_Table *h, Lisp_Object key)
+lisp_hash_lookup (struct Lisp_Hash_Table *h, Lisp_Object key)
{
return hash_lookup_with_hash (h, key, hash_from_key (h, key));
}
@@ -5058,8 +5058,8 @@ hash_lookup (struct Lisp_Hash_Table *h, Lisp_Object key)
/* Look up KEY in hash table H. Return its hash value in *PHASH.
Value is the index of the entry in H matching KEY, or -1 if not found. */
ptrdiff_t
-hash_lookup_get_hash (struct Lisp_Hash_Table *h, Lisp_Object key,
- hash_hash_t *phash)
+lisp_hash_lookup_get_hash (struct Lisp_Hash_Table *h, Lisp_Object key,
+ hash_hash_t *phash)
{
EMACS_UINT hash = hash_from_key (h, key);
*phash = hash;
@@ -5078,8 +5078,8 @@ check_mutable_hash_table (Lisp_Object obj, struct Lisp_Hash_Table *h)
Value is the index of the entry in H matching KEY. */
ptrdiff_t
-hash_put (struct Lisp_Hash_Table *h, Lisp_Object key, Lisp_Object value,
- hash_hash_t hash)
+lisp_hash_put (struct Lisp_Hash_Table *h, Lisp_Object key, Lisp_Object value,
+ hash_hash_t hash)
{
eassert (!hash_unused_entry_key_p (key));
/* Increment count after resizing because resizing may fail. */
@@ -5107,7 +5107,7 @@ hash_put (struct Lisp_Hash_Table *h, Lisp_Object key, Lisp_Object value,
/* Remove the entry matching KEY from hash table H, if there is one. */
void
-hash_remove_from_table (struct Lisp_Hash_Table *h, Lisp_Object key)
+lisp_hash_remove_from_table (struct Lisp_Hash_Table *h, Lisp_Object key)
{
hash_hash_t hashval = hash_from_key (h, key);
ptrdiff_t start_of_bucket = hash_index_index (h, hashval);
@@ -5288,7 +5288,7 @@ #define SXHASH_MAX_LEN 7
can be any EMACS_UINT value. */
EMACS_UINT
-hash_string (char const *ptr, ptrdiff_t len)
+lisp_hash_string (char const *ptr, ptrdiff_t len)
{
char const *p = ptr;
char const *end = ptr + len;
@@ -5461,7 +5461,7 @@ sxhash_obj (Lisp_Object obj, int depth)
return XHASH (obj);
case Lisp_String:
- return hash_string (SSDATA (obj), SBYTES (obj));
+ return lisp_hash_string (SSDATA (obj), SBYTES (obj));
case Lisp_Vectorlike:
{
@@ -5863,7 +5863,7 @@ DEFUN ("gethash", Fgethash, Sgethash, 2, 3, 0,
(Lisp_Object key, Lisp_Object table, Lisp_Object dflt)
{
struct Lisp_Hash_Table *h = check_hash_table (table);
- ptrdiff_t i = hash_lookup (h, key);
+ ptrdiff_t i = lisp_hash_lookup (h, key);
return i >= 0 ? HASH_VALUE (h, i) : dflt;
}
@@ -5882,7 +5882,7 @@ DEFUN ("puthash", Fputhash, Sputhash, 3, 3, 0,
if (i >= 0)
set_hash_value_slot (h, i, value);
else
- hash_put (h, key, value, hash);
+ lisp_hash_put (h, key, value, hash);
return value;
}
@@ -5894,7 +5894,7 @@ DEFUN ("remhash", Fremhash, Sremhash, 2, 2, 0,
{
struct Lisp_Hash_Table *h = check_hash_table (table);
check_mutable_hash_table (table, h);
- hash_remove_from_table (h, key);
+ lisp_hash_remove_from_table (h, key);
return Qnil;
}
diff --git a/src/image.c b/src/image.c
index 65d8db24adc..b6f04a275fd 100644
--- a/src/image.c
+++ b/src/image.c
@@ -5552,7 +5552,7 @@ xpm_free_color_cache (void)
static int
xpm_color_bucket (char *color_name)
{
- EMACS_UINT hash = hash_string (color_name, strlen (color_name));
+ EMACS_UINT hash = lisp_hash_string (color_name, strlen (color_name));
return hash % XPM_COLOR_CACHE_BUCKETS;
}
@@ -6238,8 +6238,8 @@ xpm_put_color_table_h (Lisp_Object color_table,
Lisp_Object chars = make_unibyte_string (chars_start, chars_len);
hash_hash_t hash_code;
- hash_lookup_get_hash (table, chars, &hash_code);
- hash_put (table, chars, color, hash_code);
+ lisp_hash_lookup_get_hash (table, chars, &hash_code);
+ lisp_hash_put (table, chars, color, hash_code);
}
static Lisp_Object
@@ -6249,7 +6249,7 @@ xpm_get_color_table_h (Lisp_Object color_table,
{
struct Lisp_Hash_Table *table = XHASH_TABLE (color_table);
ptrdiff_t i =
- hash_lookup (table, make_unibyte_string (chars_start, chars_len));
+ lisp_hash_lookup (table, make_unibyte_string (chars_start, chars_len));
return i >= 0 ? HASH_VALUE (table, i) : Qnil;
}
diff --git a/src/json.c b/src/json.c
index 5795c582ce0..f633215aca0 100644
--- a/src/json.c
+++ b/src/json.c
@@ -1571,9 +1571,9 @@ json_parse_object (struct json_parser *parser)
hash_hash_t hash;
Lisp_Object key = parser->object_workspace[i];
Lisp_Object value = parser->object_workspace[i + 1];
- ptrdiff_t i = hash_lookup_get_hash (h, key, &hash);
+ ptrdiff_t i = lisp_hash_lookup_get_hash (h, key, &hash);
if (i < 0)
- hash_put (h, key, value, hash);
+ lisp_hash_put (h, key, value, hash);
else
set_hash_value_slot (h, i, value);
}
diff --git a/src/lisp.h b/src/lisp.h
index 243e8cc7f36..6d78836db3d 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4261,17 +4261,17 @@ #define CONS_TO_INTEGER(cons, type, var) \
extern bool sweep_weak_table (struct Lisp_Hash_Table *, bool);
extern void hexbuf_digest (char *, void const *, int);
extern char *extract_data_from_object (Lisp_Object, ptrdiff_t *, ptrdiff_t *);
-EMACS_UINT hash_string (char const *, ptrdiff_t);
+EMACS_UINT lisp_hash_string (char const *, ptrdiff_t);
EMACS_UINT sxhash (Lisp_Object);
Lisp_Object make_hash_table (const struct hash_table_test *, EMACS_INT,
hash_table_weakness_t);
Lisp_Object hash_table_weakness_symbol (hash_table_weakness_t weak);
-ptrdiff_t hash_lookup (struct Lisp_Hash_Table *, Lisp_Object);
-ptrdiff_t hash_lookup_get_hash (struct Lisp_Hash_Table *h, Lisp_Object key,
- hash_hash_t *phash);
-ptrdiff_t hash_put (struct Lisp_Hash_Table *, Lisp_Object, Lisp_Object,
- hash_hash_t);
-void hash_remove_from_table (struct Lisp_Hash_Table *, Lisp_Object);
+ptrdiff_t lisp_hash_lookup (struct Lisp_Hash_Table *, Lisp_Object);
+ptrdiff_t lisp_hash_lookup_get_hash (struct Lisp_Hash_Table *h, Lisp_Object key,
+ hash_hash_t *phash);
+ptrdiff_t lisp_hash_put (struct Lisp_Hash_Table *, Lisp_Object, Lisp_Object,
+ hash_hash_t);
+void lisp_hash_remove_from_table (struct Lisp_Hash_Table *, Lisp_Object);
extern struct hash_table_test const hashtest_eq, hashtest_eql, hashtest_equal;
extern void validate_subarray (Lisp_Object, Lisp_Object, Lisp_Object,
ptrdiff_t, ptrdiff_t *, ptrdiff_t *);
diff --git a/src/lread.c b/src/lread.c
index add8deb3954..90759c9386c 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -4258,12 +4258,12 @@ read0 (Lisp_Object readcharfun, bool locate_syms)
= XHASH_TABLE (read_objects_map);
Lisp_Object number = make_fixnum (n);
hash_hash_t hash;
- ptrdiff_t i = hash_lookup_get_hash (h, number, &hash);
+ ptrdiff_t i = lisp_hash_lookup_get_hash (h, number, &hash);
if (i >= 0)
/* Not normal, but input could be malformed. */
set_hash_value_slot (h, i, placeholder);
else
- hash_put (h, number, placeholder, hash);
+ lisp_hash_put (h, number, placeholder, hash);
read_stack_push ((struct read_stack_entry) {
.type = RE_numbered,
.u.numbered.number = number,
@@ -4276,7 +4276,7 @@ read0 (Lisp_Object readcharfun, bool locate_syms)
/* #N# -- reference to numbered object */
struct Lisp_Hash_Table *h
= XHASH_TABLE (read_objects_map);
- ptrdiff_t i = hash_lookup (h, make_fixnum (n));
+ ptrdiff_t i = lisp_hash_lookup (h, make_fixnum (n));
if (i < 0)
INVALID_SYNTAX_WITH_BUFFER ();
obj = HASH_VALUE (h, i);
@@ -4571,9 +4571,9 @@ read0 (Lisp_Object readcharfun, bool locate_syms)
struct Lisp_Hash_Table *h2
= XHASH_TABLE (read_objects_completed);
hash_hash_t hash;
- ptrdiff_t i = hash_lookup_get_hash (h2, placeholder, &hash);
+ ptrdiff_t i = lisp_hash_lookup_get_hash (h2, placeholder, &hash);
eassert (i < 0);
- hash_put (h2, placeholder, Qnil, hash);
+ lisp_hash_put (h2, placeholder, Qnil, hash);
obj = placeholder;
}
else
@@ -4586,9 +4586,9 @@ read0 (Lisp_Object readcharfun, bool locate_syms)
struct Lisp_Hash_Table *h2
= XHASH_TABLE (read_objects_completed);
hash_hash_t hash;
- ptrdiff_t i = hash_lookup_get_hash (h2, obj, &hash);
+ ptrdiff_t i = lisp_hash_lookup_get_hash (h2, obj, &hash);
eassert (i < 0);
- hash_put (h2, obj, Qnil, hash);
+ lisp_hash_put (h2, obj, Qnil, hash);
}
/* Now put it everywhere the placeholder was... */
@@ -4598,7 +4598,7 @@ read0 (Lisp_Object readcharfun, bool locate_syms)
/* ...and #n# will use the real value from now on. */
struct Lisp_Hash_Table *h = XHASH_TABLE (read_objects_map);
hash_hash_t hash;
- ptrdiff_t i = hash_lookup_get_hash (h, e->u.numbered.number,
+ ptrdiff_t i = lisp_hash_lookup_get_hash (h, e->u.numbered.number,
&hash);
eassert (i >= 0);
set_hash_value_slot (h, i, obj);
@@ -4653,7 +4653,7 @@ substitute_object_recurse (struct subst *subst, Lisp_Object subtree)
by #n=, which means that we can find it as a value in
COMPLETED. */
if (EQ (subst->completed, Qt)
- || hash_lookup (XHASH_TABLE (subst->completed), subtree) >= 0)
+ || lisp_hash_lookup (XHASH_TABLE (subst->completed), subtree) >= 0)
subst->seen = Fcons (subtree, subst->seen);
/* Recurse according to subtree's type.
@@ -5165,7 +5165,7 @@ DEFUN ("unintern", Funintern, Sunintern, 2, 2, 0,
static ptrdiff_t
obarray_index (struct Lisp_Obarray *oa, const char *str, ptrdiff_t size_byte)
{
- EMACS_UINT hash = hash_string (str, size_byte);
+ EMACS_UINT hash = lisp_hash_string (str, size_byte);
return knuth_hash (reduce_emacs_uint_to_hash_hash (hash), oa->size_bits);
}
diff --git a/src/minibuf.c b/src/minibuf.c
index b0d54bd51f0..234d730aac0 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -2103,7 +2103,7 @@ DEFUN ("test-completion", Ftest_completion, Stest_completion, 2, 3, 0,
else if (HASH_TABLE_P (collection))
{
struct Lisp_Hash_Table *h = XHASH_TABLE (collection);
- ptrdiff_t i = hash_lookup (h, string);
+ ptrdiff_t i = lisp_hash_lookup (h, string);
if (i >= 0)
{
tem = HASH_KEY (h, i);
--
2.35.1
--pgp-sign-Multipart_Wed_Apr__2_20:45:53_2025-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQTWEnAIIlcZX4oAawJie18UwlnHhQUCZ+4EdAAKCRBie18UwlnH
hT7SAJ4ntWUB8fYfLbKnUyyA1I3MhMuulQCfeb36PVPwdaeJlkC/wAlTPHHASkk=
=U6lM
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Wed_Apr__2_20:45:53_2025-1--
"Greg A. Woods" <woods@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#77476; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.