GNU bug report logs - #77476
[PATCH] Rename various hash functions to avoid clashing with GnuTLS.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77476 in the body.
You can then email your comments to 77476 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Greg A. Woods" <woods <at> robohack.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.
Date: Wed, 02 Apr 2025 20:46:03 -0700

[Message part 1 (text/plain, inline)]

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

[Message part 2 (application/pgp-signature, inline)]

Message #8 received at 77476 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Greg A. Woods" <woods <at> robohack.ca>
Cc: 77476 <at> debbugs.gnu.org
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing
 with GnuTLS.
Date: Thu, 03 Apr 2025 08:25:15 +0300

> Date: Wed, 02 Apr 2025 20:46:03 -0700
> From: "Greg A. Woods" <woods <at> robohack.ca>
> 
> 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 #13 received at 77476 <at> debbugs.gnu.org (full text, mbox):

From: "Greg A. Woods" <woods <at> robohack.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77476 <at> debbugs.gnu.org
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid
 clashing with GnuTLS.
Date: Thu, 03 Apr 2025 13:00:57 -0700

[Message part 1 (text/plain, inline)]

At Thu, 03 Apr 2025 08:25:15 +0300, Eli Zaretskii <eliz <at> gnu.org> 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 <at> robohack.ca>
> >
> > 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 <at> acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods <at> robohack.ca>
Planix, Inc. <woods <at> planix.com>     Avoncote Farms <woods <at> avoncote.ca>

[Message part 2 (application/pgp-signature, inline)]

Message #16 received at 77476 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Greg A. Woods" <woods <at> robohack.ca>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 77476 <at> debbugs.gnu.org
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid
 clashing with GnuTLS.
Date: Fri, 04 Apr 2025 13:40:50 +0300

> Date: Thu, 03 Apr 2025 13:00:57 -0700
> From: "Greg A. Woods" <woods <at> robohack.ca>
> 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 #21 received at 77476 <at> debbugs.gnu.org (full text, mbox):

From: "Greg A. Woods" <woods <at> robohack.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77476 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid
 clashing with GnuTLS.
Date: Fri, 04 Apr 2025 12:19:29 -0700

[Message part 1 (text/plain, inline)]

At Fri, 04 Apr 2025 13:40:50 +0300, Eli Zaretskii <eliz <at> gnu.org> 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 <at> acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods <at> robohack.ca>
Planix, Inc. <woods <at> planix.com>     Avoncote Farms <woods <at> avoncote.ca>

[Message part 2 (application/pgp-signature, inline)]

Message #24 received at 77476 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: eggert <at> cs.ucla.edu
Cc: 77476 <at> debbugs.gnu.org, woods <at> robohack.ca
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing
 with GnuTLS.
Date: Sat, 19 Apr 2025 16:50:12 +0300

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 <at> gnu.org>
> 
> > Date: Thu, 03 Apr 2025 13:00:57 -0700
> > From: "Greg A. Woods" <woods <at> robohack.ca>
> > 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 #29 received at 77476-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77476-done <at> debbugs.gnu.org, woods <at> robohack.ca
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid
 clashing with GnuTLS.
Date: Sat, 19 Apr 2025 22:32:44 -0700

[Message part 1 (text/plain, inline)]

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.

[0001-Avoid-name-clashes-with-static-GnuTLS.patch (text/x-patch, attachment)]

Message #34 received at 77476-done <at> debbugs.gnu.org (full text, mbox):

From: "Greg A. Woods" <woods <at> robohack.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77476-done <at> debbugs.gnu.org
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid
 clashing with GnuTLS.
Date: Sat, 19 Apr 2025 23:30:39 -0700

At Sat, 19 Apr 2025 22:32:44 -0700, Paul Eggert <eggert <at> cs.ucla.edu> 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 <at> acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods <at> robohack.ca>
Planix, Inc. <woods <at> planix.com>     Avoncote Farms <woods <at> avoncote.ca>

Message #37 received at 77476 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 77476 <at> debbugs.gnu.org, woods <at> robohack.ca
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid
 clashing with GnuTLS.
Date: Sun, 20 Apr 2025 11:04:19 +0300

> Date: Sat, 19 Apr 2025 22:32:44 -0700
> Cc: woods <at> robohack.ca, 77476-done <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> 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.

Ah, okay.  So this is a clash of Gnulib with itself, due to incorrect
visibility specs applied by GnuTLS...

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

Thanks.

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

I agree.

Message #40 received at 77476 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77476 <at> debbugs.gnu.org, woods <at> robohack.ca
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid
 clashing with GnuTLS.
Date: Sun, 20 Apr 2025 13:25:07 -0700

On 2025-04-20 01:04, Eli Zaretskii wrote:
>> GnuTLS incorrectly exports some Gnulib functions to the outside world,
>> and this breaks programs that use these function names for their own
>> purposes.
> Ah, okay.  So this is a clash of Gnulib with itself, due to incorrect
> visibility specs applied by GnuTLS...

The clash was not of Gnulib with itself, since the part of Gnulib that 
defines these symbols is not present in the Emacs tarball. Instead, the 
clash was between Emacs's hash_lookup and hash_string (defined in 
emacs/src/fns.c) and Gnulib's hash_lookup and hash_string (defined in 
gnulib/lib/hash.c) incorrectly exported by GnuTLS's x509 implementation, 
which is used by emacs/src/gnutls.c.

Previous Next

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