GNU logs - #77476, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.
Resent-From: "Greg A. Woods" <woods@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 03 Apr 2025 03:47:02 +0000
Resent-Message-ID: <handler.77476.B.174365199316545 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 77476 <at> debbugs.gnu.org
Message-Id: <m1u0BWl-00NOtVC@HIDDEN>
Date: Wed, 02 Apr 2025 20:46:03 -0700
From: "Greg A. Woods" <woods@HIDDEN>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?Q?Goj=C5=8D?=) APEL-LB/10.8 EasyPG/1.0.0
 Emacs/27.2 (x86_64-unknown-netbsd) MULE/6.0 (HANACHIRUSATO)
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-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--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Greg A. Woods" <woods@HIDDEN>
Subject: bug#77476: Acknowledgement ([PATCH] Rename various hash functions
 to avoid clashing with GnuTLS.)
Message-ID: <handler.77476.B.174365199316545.ack <at> debbugs.gnu.org>
References: <m1u0BWl-00NOtVC@HIDDEN>
X-Gnu-PR-Message: ack 77476
X-Gnu-PR-Package: emacs
X-Gnu-PR-Keywords: patch
Reply-To: 77476 <at> debbugs.gnu.org
Date: Thu, 03 Apr 2025 03:47:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 77476 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
77476: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77476
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 03 Apr 2025 05:26:02 +0000
Resent-Message-ID: <handler.77476.B77476.174365793025086 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "Greg A. Woods" <woods@HIDDEN>
Cc: 77476 <at> debbugs.gnu.org
Date: Thu, 03 Apr 2025 08:25:15 +0300
Message-Id: <86zfgxzuis.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <m1u0BWl-00NOtVC@HIDDEN> (woods@HIDDEN)
References: <m1u0BWl-00NOtVC@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> 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".

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.
Resent-From: "Greg A. Woods" <woods@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 03 Apr 2025 20:02:01 +0000
Resent-Message-ID: <handler.77476.B77476.174371047227550 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 77476 <at> debbugs.gnu.org
Message-Id: <m1u0QkE-00N3he0@HIDDEN>
Date: Thu, 03 Apr 2025 13:00:57 -0700
From: "Greg A. Woods" <woods@HIDDEN>
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 (=?UTF-8?Q?Goj=C5=8D?=) APEL-LB/10.8 EasyPG/1.0.0
 Emacs/27.2 (x86_64-unknown-netbsd) MULE/6.0 (HANACHIRUSATO)
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
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--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--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Greg A. Woods" <woods@HIDDEN>
Subject: bug#77476: Info received (bug#77476: [PATCH] Rename various hash
 functions to avoid clashing with GnuTLS.)
Message-ID: <handler.77476.B77476.174371047227550.ackinfo <at> debbugs.gnu.org>
References: <m1u0QkE-00N3he0@HIDDEN>
X-Gnu-PR-Message: ack-info 77476
X-Gnu-PR-Package: emacs
X-Gnu-PR-Keywords: patch
Reply-To: 77476 <at> debbugs.gnu.org
Date: Thu, 03 Apr 2025 20:02:02 +0000

Thank you for the additional information you have supplied regarding
this bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 77476 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
77476: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77476
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 04 Apr 2025 10:42:02 +0000
Resent-Message-ID: <handler.77476.B77476.174376326312369 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77476
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: "Greg A. Woods" <woods@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Cc: 77476 <at> debbugs.gnu.org
Received: via spool by 77476-submit <at> debbugs.gnu.org id=B77476.174376326312369
          (code B ref 77476); Fri, 04 Apr 2025 10:42:02 +0000
Received: (at 77476) by debbugs.gnu.org; 4 Apr 2025 10:41:03 +0000
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>
In-Reply-To: <m1u0QkE-00N3he0@HIDDEN> (woods@HIDDEN)
References: <m1u0BWl-00NOtVC@HIDDEN>
 <86zfgxzuis.fsf@HIDDEN> <m1u0QkE-00N3he0@HIDDEN>
X-Spam-Score: -2.3 (--)
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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.
Resent-From: "Greg A. Woods" <woods@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 04 Apr 2025 19:20:02 +0000
Resent-Message-ID: <handler.77476.B77476.174379439028785 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 77476
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 77476 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
Received: via spool by 77476-submit <at> debbugs.gnu.org id=B77476.174379439028785
          (code B ref 77476); Fri, 04 Apr 2025 19:20:02 +0000
Received: (at 77476) by debbugs.gnu.org; 4 Apr 2025 19:19:50 +0000
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>
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 (=?UTF-8?Q?Goj=C5=8D?=) 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-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--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Greg A. Woods" <woods@HIDDEN>
Subject: bug#77476: Info received (bug#77476: [PATCH] Rename various hash
 functions to avoid clashing with GnuTLS.)
Message-ID: <handler.77476.B77476.174379439028785.ackinfo <at> debbugs.gnu.org>
References: <m1u0mZd-00NOtV0@HIDDEN>
X-Gnu-PR-Message: ack-info 77476
X-Gnu-PR-Package: emacs
X-Gnu-PR-Keywords: patch
Reply-To: 77476 <at> debbugs.gnu.org
Date: Fri, 04 Apr 2025 19:20:02 +0000

Thank you for the additional information you have supplied regarding
this bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 77476 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
77476: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77476
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Last modified: Fri, 4 Apr 2025 19:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.