Re: [commit] Deprecate remaining STREQ uses

Re: [commit] Deprecate remaining STREQ uses

[Michael Elizabeth Chastain]

Andrew Cagney writes:
> modify
> build
> test
> submit
> review
> commit

I'd like to go off on a bit of a tangent here.

When I submit a patch, I describe how I tested the patch.  I'm also
in the habit of asking people how they tested their patches when I'm
reviewing other people's patches.

I'd like this to become a mandatory part of a patch submission,
just like a ChangeLog entry is a mandatory part.

I'm not advocating for any particular minimum level of testing.
If someone says "Testing: I built gdb and it still compiled",
that is okay for some patches.  Indeed, I submitted a patch like
that for dwarfread.c this week, and a maintainer approved it.

In fact I am opposed to a high level of testing before committing
patches on the mainline.  Most patches never cause a problem.  As long
as it stays that way, it's more efficient for people to commit patches,
and then I test them in my next spin, and if there's a regression, I
isolate it pretty fast.  It's like interrupt processing on a deeply
pipelined processor, the processor gets more throughput at the cost of
more state to manage when an interrupt does happen.

The testing requirement would do two things.  First, just because it's
there, people would do some minimal amount of testing so that they don't
look lame in public.  Second, if a problem does occur with the patch,
then when somebody else is analyzing the problem, they have some idea of
how the patch was tested before it was integrated.

(When I was working on the linux kernel, frequently people would submit
patches and say "I didn't even compile this yet but here's the idea
...".  We handle this with RFC instead, so we don't have this problem.)

I dunno if gdb can handle a formal process change to do this.  We're all
pretty busy these days.  But if anybody shares my views, you can do this
yourself: say how you tested your patches, and ask people to include
this information in a patch when they review it.

Michael C

Re: [commit] Deprecate remaining STREQ uses

[Michael Elizabeth Chastain]

My two cents:

(1) I don't like it when patches are chained to other work.
    ("You must do Y if you touch X".)  If fixing X is good,
    and it does not make Y _worse_, then I'm fine with X alone.
    I know this isn't gdb policy but it's my preference.
    One exception to this is copyright notices.

(2) The problem with cleaning up old code is that there's so much
    code which never gets tested.  That's a QA problem.  I would
    like to test more, and I've just recently gotten access to
    HP's test drive.
    
    But basically, I think we should be more aggressive about
    deprecating things.  If nobody submits test results for a platform
    to the gdb-testers group for a long time, then I would like to drop
    that platform.

Michael C

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Fri, 12 Dec 2003 14:49:29 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
>     
>     But basically, I think we should be more aggressive about
>     deprecating things.  If nobody submits test results for a platform
>     to the gdb-testers group for a long time, then I would like to drop
>     that platform.

I disagree.  I think deprecating platforms should be done very
cautiously, definitely not as the default reaction to no patches being
submitted.

If you are proposing a change in the current strategy, this issue
should be discussed (on gdb@, I guess).  For startesr, please define
the ``long time'' after which it is okay, in your opinion, to
deprecate a platform.

Re: [commit] Deprecate remaining STREQ uses

[Michael Elizabeth Chastain]

Daniel J writes:
> We've even got the ARI to remind us; what you've
> accomplished is shrinking the STREQ/STREQN column to zero at the
> expense of raising the deprecated column even higher.  If that was all
> you wanted you could have done it in the ARI scripts.

This is my opinion too.

> Or am I out in a corner by myself here?

My guess is that it helps Andrew push a "todo" item out of his head into
the source code, so that he has one less thing bugging him and can get
on with something else.  Just like it drives me nuts when a file is
missing a copyright notice, and I can't do anything else until I get
the copyright notice fixed.  Everybody's got different things in their
"I gotta clean this up because it bugs me too much" property list.

Just my guess.  Actually it's rude of me to guess about Andrew's
motives!

Michael C

[commit] Deprecate remaining STREQ uses

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

Hello,

This patch deprecates remaining STREQ and STREQ uses.  These are the 
ones that weren't covered by my testing GDB on a stabs system.  It is 
worth noting that the bulk occure in language specific files - this 
suggests an area that needs improved testsuite coverage.

committed,
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 51022 bytes --]

2003-11-23  Andrew Cagney  <cagney@redhat.com>

	* symfile.c (symbol_file_command): Replace STREQ with strcmp.
	* defs.h (DEPRECATED_STREQN): Rename STREQN.
	(DEPRECATED_STREQ): Rename STREQ.
	* ada-exp.y, ada-lang.c, ada-lex.l, coffread.c: Update.
	* config/mips/tm-irix5.h, config/mips/tm-irix6.h: Update.
	* config/mips/tm-mipsv4.h, config/sparc/tm-sun4sol2.h: Update.
	* dbxread.c, dwarf2read.c, dwarfread.c, environ.c: Update.
	* eval.c, exec.c, f-lang.c, hppa-tdep.c, hpread.c: Update.
	* jv-exp.y, language.c, m2-exp.y, mcore-rom.c: Update.
	* mdebugread.c, mipsread.c, objc-exp.y, objfiles.c: Update.
	* p-exp.y, p-typeprint.c, p-valprint.c, rs6000-nat.c: Update.
	* source.c, sparc-tdep.c, stack.c, target.c: Update.
 
Index: ada-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/ada-exp.y,v
retrieving revision 1.7
diff -u -r1.7 ada-exp.y
--- ada-exp.y	14 May 2003 17:43:15 -0000	1.7
+++ ada-exp.y	23 Nov 2003 20:08:34 -0000
@@ -823,7 +823,7 @@
 	  simple_tail += 1;
 	  break;
 	} 
-      else if (STREQN (simple_tail, "__", 2))
+      else if (DEPRECATED_STREQN (simple_tail, "__", 2))
 	{
 	  simple_tail += 2;
 	  break;
@@ -962,7 +962,7 @@
   sprintf (name, "QU%02x", (int) val);
   for (f = 0; f < TYPE_NFIELDS (type); f += 1) 
     {
-      if (STREQ (name, TYPE_FIELD_NAME (type, f)))
+      if (DEPRECATED_STREQ (name, TYPE_FIELD_NAME (type, f)))
 	return TYPE_FIELD_BITPOS (type, f);
     }
   return val;
Index: ada-lang.c
===================================================================
RCS file: /cvs/src/src/gdb/ada-lang.c,v
retrieving revision 1.33
diff -u -r1.33 ada-lang.c
--- ada-lang.c	6 Oct 2003 22:37:37 -0000	1.33
+++ ada-lang.c	23 Nov 2003 20:09:30 -0000
@@ -253,10 +253,10 @@
 {
   int len = strlen (target);
   return
-    STREQN (field_name, target, len)
+    DEPRECATED_STREQN (field_name, target, len)
     && (field_name[len] == '\0'
-	|| (STREQN (field_name + len, "___", 3)
-	    && !STREQ (field_name + strlen (field_name) - 6, "___XVN")));
+	|| (DEPRECATED_STREQN (field_name + len, "___", 3)
+	    && !DEPRECATED_STREQ (field_name + strlen (field_name) - 6, "___XVN")));
 }
 
 
@@ -286,7 +286,7 @@
     return 0;
   len1 = strlen (str);
   len2 = strlen (suffix);
-  return (len1 >= len2 && STREQ (str + len1 - len2, suffix));
+  return (len1 >= len2 && DEPRECATED_STREQ (str + len1 - len2, suffix));
 }
 
 /* Create a value of type TYPE whose contents come from VALADDR, if it
@@ -437,7 +437,7 @@
 static int
 is_suppressed_name (const char *str)
 {
-  if (STREQN (str, "_ada_", 5))
+  if (DEPRECATED_STREQN (str, "_ada_", 5))
     str += 5;
   if (str[0] == '_' || str[0] == '\000')
     return 1;
@@ -458,7 +458,7 @@
 	    if (*p != 'O')
 	      return 1;
 	    for (i = 0; ada_opname_table[i].mangled != NULL; i += 1)
-	      if (STREQN (ada_opname_table[i].mangled, p,
+	      if (DEPRECATED_STREQN (ada_opname_table[i].mangled, p,
 			  strlen (ada_opname_table[i].mangled)))
 		goto OK;
 	    return 1;
@@ -498,7 +498,7 @@
 
 	  for (mapping = ada_opname_table;
 	       mapping->mangled != NULL &&
-	       !STREQN (mapping->demangled, p, strlen (mapping->demangled));
+	       !DEPRECATED_STREQN (mapping->demangled, p, strlen (mapping->demangled));
 	       p += 1)
 	    ;
 	  if (mapping->mangled == NULL)
@@ -569,7 +569,7 @@
   static char *demangling_buffer = NULL;
   static size_t demangling_buffer_size = 0;
 
-  if (STREQN (mangled, "_ada_", 5))
+  if (DEPRECATED_STREQN (mangled, "_ada_", 5))
     mangled += 5;
 
   if (mangled[0] == '_' || mangled[0] == '<')
@@ -585,9 +585,9 @@
       else
 	goto Suppress;
     }
-  if (len0 > 3 && STREQ (mangled + len0 - 3, "TKB"))
+  if (len0 > 3 && DEPRECATED_STREQ (mangled + len0 - 3, "TKB"))
     len0 -= 3;
-  if (len0 > 1 && STREQ (mangled + len0 - 1, "B"))
+  if (len0 > 1 && DEPRECATED_STREQ (mangled + len0 - 1, "B"))
     len0 -= 1;
 
   /* Make demangled big enough for possible expansion by operator name. */
@@ -616,7 +616,7 @@
 	  for (k = 0; ada_opname_table[k].mangled != NULL; k += 1)
 	    {
 	      int op_len = strlen (ada_opname_table[k].mangled);
-	      if (STREQN
+	      if (DEPRECATED_STREQN
 		  (ada_opname_table[k].mangled + 1, mangled + i + 1,
 		   op_len - 1) && !isalnum (mangled[i + op_len]))
 		{
@@ -632,7 +632,7 @@
 	}
       at_start_name = 0;
 
-      if (i < len0 - 4 && STREQN (mangled + i, "TK__", 4))
+      if (i < len0 - 4 && DEPRECATED_STREQN (mangled + i, "TK__", 4))
 	i += 2;
       if (mangled[i] == 'X' && i != 0 && isalnum (mangled[i - 1]))
 	{
@@ -692,10 +692,10 @@
   else
     {
       int len_name = strlen (name);
-      return (STREQN (sym_name, name, len_name)
+      return (DEPRECATED_STREQN (sym_name, name, len_name)
 	      && is_name_suffix (sym_name + len_name))
-	|| (STREQN (sym_name, "_ada_", 5)
-	    && STREQN (sym_name + 5, name, len_name)
+	|| (DEPRECATED_STREQN (sym_name, "_ada_", 5)
+	    && DEPRECATED_STREQN (sym_name + 5, name, len_name)
 	    && is_name_suffix (sym_name + len_name + 5));
     }
 }
@@ -1236,7 +1236,7 @@
 			      VAR_DOMAIN, &syms, &blocks);
   for (i = 0; i < n; i += 1)
     if (syms[i] != NULL && SYMBOL_CLASS (syms[i]) == LOC_TYPEDEF
-	&& STREQ (name, ada_type_name (SYMBOL_TYPE (syms[i]))))
+	&& DEPRECATED_STREQ (name, ada_type_name (SYMBOL_TYPE (syms[i]))))
       break;
   if (i >= n)
     {
@@ -2545,7 +2545,7 @@
 	  n1 = k1;
 	  while (N1[n1] == '_' && n1 > 0 && N1[n1 - 1] == '_')
 	    n1 -= 1;
-	  if (n0 == n1 && STREQN (N0, N1, n0))
+	  if (n0 == n1 && DEPRECATED_STREQN (N0, N1, n0))
 	    return (atoi (N0 + k0 + 1) < atoi (N1 + k1 + 1));
 	}
       return (strcmp (N0, N1) < 0);
@@ -3217,7 +3217,7 @@
   if ((TYPE_CODE (type0) == TYPE_CODE_STRUCT
        || TYPE_CODE (type0) == TYPE_CODE_ENUM)
       && ada_type_name (type0) != NULL && ada_type_name (type1) != NULL
-      && STREQ (ada_type_name (type0), ada_type_name (type1)))
+      && DEPRECATED_STREQ (ada_type_name (type0), ada_type_name (type1)))
     return 1;
 
   return 0;
@@ -3249,8 +3249,8 @@
 	return
 	  TYPE_CODE (type0) == TYPE_CODE (type1)
 	  && (equiv_types (type0, type1)
-	      || (len0 < strlen (name1) && STREQN (name0, name1, len0)
-		  && STREQN (name1 + len0, "___XV", 5)));
+	      || (len0 < strlen (name1) && DEPRECATED_STREQN (name0, name1, len0)
+		  && DEPRECATED_STREQN (name1 + len0, "___XV", 5)));
       }
     case LOC_CONST:
       return SYMBOL_VALUE (sym0) == SYMBOL_VALUE (sym1)
@@ -3583,7 +3583,7 @@
 is_nondebugging_type (struct type *type)
 {
   char *name = ada_type_name (type);
-  return (name != NULL && STREQ (name, "<variable, no debug info>"));
+  return (name != NULL && DEPRECATED_STREQ (name, "<variable, no debug info>"));
 }
 
 /* Remove any non-debugging symbols in SYMS[0 .. NSYMS-1] that definitely 
@@ -3610,7 +3610,7 @@
 	    {
 	      if (i != j
 		  && DEPRECATED_SYMBOL_NAME (syms[j]) != NULL
-		  && STREQ (DEPRECATED_SYMBOL_NAME (syms[i]), DEPRECATED_SYMBOL_NAME (syms[j]))
+		  && DEPRECATED_STREQ (DEPRECATED_SYMBOL_NAME (syms[i]), DEPRECATED_SYMBOL_NAME (syms[j]))
 		  && SYMBOL_CLASS (syms[i]) == SYMBOL_CLASS (syms[j])
 		  && SYMBOL_VALUE_ADDRESS (syms[i])
 		  == SYMBOL_VALUE_ADDRESS (syms[j]))
@@ -3863,7 +3863,7 @@
 	return 0;
       if (str[2] == '_')
 	{
-	  if (STREQ (str + 3, "LJM"))
+	  if (DEPRECATED_STREQ (str + 3, "LJM"))
 	    return 1;
 	  if (str[3] != 'X')
 	    return 0;
@@ -3900,14 +3900,14 @@
   int s, e;
 
   name_len = strlen (name);
-  if (name_len >= patn_len + 5 && STREQN (name, "_ada_", 5)
-      && STREQN (patn, name + 5, patn_len)
+  if (name_len >= patn_len + 5 && DEPRECATED_STREQN (name, "_ada_", 5)
+      && DEPRECATED_STREQN (patn, name + 5, patn_len)
       && is_name_suffix (name + patn_len + 5))
     return 1;
 
   while (name_len >= patn_len)
     {
-      if (STREQN (patn, name, patn_len) && is_name_suffix (name + patn_len))
+      if (DEPRECATED_STREQN (patn, name, patn_len) && is_name_suffix (name + patn_len))
 	return 1;
       do
 	{
@@ -4454,7 +4454,7 @@
 
     QUIT;
 
-    if (!STREQ (filename, s->filename))
+    if (!DEPRECATED_STREQ (filename, s->filename))
       continue;
     l = LINETABLE (s);
     ind = find_line_in_linetable (l, line_num, symbols, nsyms, &exact);
@@ -4752,7 +4752,7 @@
   {
     QUIT;
 
-    if (STREQ (filename, ps->filename))
+    if (DEPRECATED_STREQ (filename, ps->filename))
       PSYMTAB_TO_SYMTAB (ps);
   }
 }
@@ -4783,7 +4783,7 @@
 
     QUIT;
 
-    if (!STREQ (s->filename, filename))
+    if (!DEPRECATED_STREQ (s->filename, filename))
       continue;
 
     target_line_num =
@@ -4961,9 +4961,9 @@
 int
 is_ada_runtime_file (char *filename)
 {
-  return (STREQN (filename, "s-", 2) ||
-	  STREQN (filename, "a-", 2) ||
-	  STREQN (filename, "g-", 2) || STREQN (filename, "i-", 2));
+  return (DEPRECATED_STREQN (filename, "s-", 2) ||
+	  DEPRECATED_STREQN (filename, "a-", 2) ||
+	  DEPRECATED_STREQN (filename, "g-", 2) || DEPRECATED_STREQN (filename, "i-", 2));
 }
 
 /* find the first frame that contains debugging information and that is not
@@ -4984,7 +4984,7 @@
 	     from finding the right frame */
 
 	  if (sal.symtab->objfile &&
-	      STREQ (sal.symtab->objfile->name, "/usr/shlib/libpthread.so"))
+	      DEPRECATED_STREQ (sal.symtab->objfile->name, "/usr/shlib/libpthread.so"))
 	    continue;
 #endif
 	  deprecated_selected_frame = fi;
@@ -5045,7 +5045,7 @@
   return (SYMBOL_CLASS (sym) != LOC_TYPEDEF
 	  && SYMBOL_CLASS (sym) != LOC_BLOCK
 	  && SYMBOL_CLASS (sym) != LOC_CONST
-	  && type_name != NULL && STREQ (type_name, "exception"));
+	  && type_name != NULL && DEPRECATED_STREQ (type_name, "exception"));
 }
 
 int
@@ -5068,7 +5068,7 @@
   *break_on_exceptionp = 0;
   /* FIXME: language_ada should be defined in defs.h */
   /*  if (current_language->la_language == language_ada
-     && STREQN (arg, "exception", 9) &&
+     && DEPRECATED_STREQN (arg, "exception", 9) &&
      (arg[9] == ' ' || arg[9] == '\t' || arg[9] == '\0'))
      {
      char *tok, *end_tok;
@@ -5093,7 +5093,7 @@
      make_cleanup (xfree, arg);
      if (toklen == 0)
      strcpy (arg, "__gnat_raise_nodefer_with_msg");
-     else if (STREQN (tok, "unhandled", toklen))
+     else if (DEPRECATED_STREQN (tok, "unhandled", toklen))
      {
      *break_on_exceptionp = 2;
      strcpy (arg, "__gnat_unhandled_exception");
@@ -5106,7 +5106,7 @@
      }
      }
      else if (current_language->la_language == language_ada
-     && STREQN (arg, "assert", 6) &&
+     && DEPRECATED_STREQN (arg, "assert", 6) &&
      (arg[6] == ' ' || arg[6] == '\t' || arg[6] == '\0'))
      {
      char *tok = arg + 6;
@@ -5138,7 +5138,7 @@
     {
       const char *name = TYPE_FIELD_NAME (type, field_num);
       return (name == NULL
-	      || (name[0] == '_' && !STREQN (name, "_parent", 7)));
+	      || (name[0] == '_' && !DEPRECATED_STREQN (name, "_parent", 7)));
     }
 }
 
@@ -5197,7 +5197,7 @@
 {
   const char *name = TYPE_FIELD_NAME (check_typedef (type), field_num);
   return (name != NULL &&
-	  (STREQN (name, "PARENT", 6) || STREQN (name, "_parent", 7)));
+	  (DEPRECATED_STREQN (name, "PARENT", 6) || DEPRECATED_STREQN (name, "_parent", 7)));
 }
 
 /* True iff field number FIELD_NUM of structure type TYPE is a 
@@ -5211,8 +5211,8 @@
 {
   const char *name = TYPE_FIELD_NAME (type, field_num);
   return (name != NULL
-	  && (STREQN (name, "PARENT", 6) || STREQ (name, "REP")
-	      || STREQN (name, "_parent", 7)
+	  && (DEPRECATED_STREQN (name, "PARENT", 6) || DEPRECATED_STREQ (name, "REP")
+	      || DEPRECATED_STREQN (name, "_parent", 7)
 	      || name[0] == 'S' || name[0] == 'R' || name[0] == 'O'));
 }
 
@@ -5283,7 +5283,7 @@
   for (discrim_end = name + strlen (name) - 6; discrim_end != name;
        discrim_end -= 1)
     {
-      if (STREQN (discrim_end, "___XVN", 6))
+      if (DEPRECATED_STREQN (discrim_end, "___XVN", 6))
 	break;
     }
   if (discrim_end == name)
@@ -5294,7 +5294,7 @@
     {
       if (discrim_start == name + 1)
 	return "";
-      if ((discrim_start > name + 3 && STREQN (discrim_start - 3, "___", 3))
+      if ((discrim_start > name + 3 && DEPRECATED_STREQN (discrim_start - 3, "___", 3))
 	  || discrim_start[-1] == '.')
 	break;
     }
@@ -5778,7 +5778,7 @@
   else
     align_offset = len - 1;
 
-  if (align_offset < 7 || !STREQN ("___XV", name + align_offset - 6, 5))
+  if (align_offset < 7 || !DEPRECATED_STREQN ("___XV", name + align_offset - 6, 5))
     return TARGET_CHAR_BIT;
 
   return atoi (name + align_offset) * TARGET_CHAR_BIT;
@@ -5882,7 +5882,7 @@
   else
     {
       int len = strlen (ada_type_name (type));
-      if (len > 6 && STREQ (ada_type_name (type) + len - 6, "___XVE"))
+      if (len > 6 && DEPRECATED_STREQ (ada_type_name (type) + len - 6, "___XVE"))
 	return type;
       else
 	return ada_find_parallel_type (type, "___XVE");
@@ -6547,8 +6547,8 @@
     && (TYPE_CODE (type) == TYPE_CODE_CHAR
 	|| TYPE_CODE (type) == TYPE_CODE_INT
 	|| TYPE_CODE (type) == TYPE_CODE_RANGE)
-    && (STREQ (name, "character") || STREQ (name, "wide_character")
-	|| STREQ (name, "unsigned char"));
+    && (DEPRECATED_STREQ (name, "character") || DEPRECATED_STREQ (name, "wide_character")
+	|| DEPRECATED_STREQ (name, "unsigned char"));
 }
 
 /* True if TYPE appears to be an Ada string type. */
@@ -6581,7 +6581,7 @@
   CHECK_TYPEDEF (type);
   return (TYPE_CODE (type) == TYPE_CODE_STRUCT
 	  && TYPE_NFIELDS (type) == 1
-	  && STREQ (TYPE_FIELD_NAME (type, 0), "F"));
+	  && DEPRECATED_STREQ (TYPE_FIELD_NAME (type, 0), "F"));
 }
 
 /* If there is an ___XVS-convention type parallel to SUBTYPE, return
@@ -7668,7 +7668,7 @@
     name_len > 6
     && (TYPE_CODE (type) == TYPE_CODE_INT
 	|| TYPE_CODE (type) == TYPE_CODE_RANGE)
-    && STREQN (ada_type_name (type) + name_len - 6, "___XF", 5);
+    && DEPRECATED_STREQN (ada_type_name (type) + name_len - 6, "___XF", 5);
 }
 
 /* The type of special VAX floating-point type this is, assuming
Index: ada-lex.l
===================================================================
RCS file: /cvs/src/src/gdb/ada-lex.l,v
retrieving revision 1.2
diff -u -r1.2 ada-lex.l
--- ada-lex.l	17 Jun 2003 20:58:32 -0000	1.2
+++ ada-lex.l	23 Nov 2003 20:09:38 -0000
@@ -759,7 +759,7 @@
       if (segments == 0)
 	{
 	  type = lookup_primitive_typename (name);
-	  if (type == NULL && STREQ ("system__address", name))
+	  if (type == NULL && DEPRECATED_STREQ ("system__address", name))
 	    type = builtin_type_ada_system_address;
 	  if (type != NULL)
 	    {
Index: coffread.c
===================================================================
RCS file: /cvs/src/src/gdb/coffread.c,v
retrieving revision 1.49
diff -u -r1.49 coffread.c
--- coffread.c	8 Nov 2003 00:13:02 -0000	1.49
+++ coffread.c	23 Nov 2003 20:09:54 -0000
@@ -202,7 +202,7 @@
 
   csi = (struct coff_symfile_info *) csip;
   name = bfd_get_section_name (abfd, sectp);
-  if (STREQ (name, ".text"))
+  if (DEPRECATED_STREQ (name, ".text"))
     {
       csi->textaddr = bfd_section_vma (abfd, sectp);
       csi->textsize += bfd_section_size (abfd, sectp);
@@ -211,7 +211,7 @@
     {
       csi->textsize += bfd_section_size (abfd, sectp);
     }
-  else if (STREQ (name, ".stabstr"))
+  else if (DEPRECATED_STREQ (name, ".stabstr"))
     {
       csi->stabstrsect = sectp;
     }
@@ -819,7 +819,7 @@
 	case C_THUMBSTATFUNC:
 	  if (cs->c_name[0] == '.')
 	    {
-	      if (STREQ (cs->c_name, ".text"))
+	      if (DEPRECATED_STREQ (cs->c_name, ".text"))
 		{
 		  /* FIXME:  don't wire in ".text" as section name
 		     or symbol name! */
@@ -944,7 +944,7 @@
 	  break;
 
 	case C_FCN:
-	  if (STREQ (cs->c_name, ".bf"))
+	  if (DEPRECATED_STREQ (cs->c_name, ".bf"))
 	    {
 	      within_function = 1;
 
@@ -966,7 +966,7 @@
 	      new->name =
 		process_coff_symbol (&fcn_cs_saved, &fcn_aux_saved, objfile);
 	    }
-	  else if (STREQ (cs->c_name, ".ef"))
+	  else if (DEPRECATED_STREQ (cs->c_name, ".ef"))
 	    {
 	      if (!within_function)
 		error ("Bad coff function information\n");
@@ -1042,13 +1042,13 @@
 	  break;
 
 	case C_BLOCK:
-	  if (STREQ (cs->c_name, ".bb"))
+	  if (DEPRECATED_STREQ (cs->c_name, ".bb"))
 	    {
 	      tmpaddr = cs->c_value;
 	      tmpaddr += ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
 	      push_context (++depth, tmpaddr);
 	    }
-	  else if (STREQ (cs->c_name, ".eb"))
+	  else if (DEPRECATED_STREQ (cs->c_name, ".eb"))
 	    {
 	      if (context_stack_depth <= 0)
 		{		/* We attempted to pop an empty context stack */
Index: dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.60
diff -u -r1.60 dbxread.c
--- dbxread.c	11 Nov 2003 20:04:52 -0000	1.60
+++ dbxread.c	23 Nov 2003 20:10:25 -0000
@@ -483,7 +483,7 @@
          Record it as global even if it's local, not global, so
          lookup_minimal_symbol can find it.  We don't check symbol_leading_char
          because for SunOS4 it always is '_'.  */
-      if (name[8] == 'C' && STREQ ("__DYNAMIC", name))
+      if (name[8] == 'C' && DEPRECATED_STREQ ("__DYNAMIC", name))
 	ms_type = mst_data;
 
       /* Same with virtual function tables, both global and static.  */
@@ -2511,13 +2511,13 @@
 	{
 	  const char *tempstring = namestring;
 
-	  if (STREQ (namestring, GCC_COMPILED_FLAG_SYMBOL))
+	  if (DEPRECATED_STREQ (namestring, GCC_COMPILED_FLAG_SYMBOL))
 	    processing_gcc_compilation = 1;
-	  else if (STREQ (namestring, GCC2_COMPILED_FLAG_SYMBOL))
+	  else if (DEPRECATED_STREQ (namestring, GCC2_COMPILED_FLAG_SYMBOL))
 	    processing_gcc_compilation = 2;
 	  if (tempstring[0] == bfd_get_symbol_leading_char (symfile_bfd))
 	    ++tempstring;
-	  if (STREQN (tempstring, "__gnu_compiled", 14))
+	  if (DEPRECATED_STREQN (tempstring, "__gnu_compiled", 14))
 	    processing_gcc_compilation = 2;
 	}
 
@@ -2583,9 +2583,9 @@
 	     However, there is no reason not to accept
 	     the GCC_COMPILED_FLAG_SYMBOL anywhere.  */
 
-	  if (STREQ (namestring, GCC_COMPILED_FLAG_SYMBOL))
+	  if (DEPRECATED_STREQ (namestring, GCC_COMPILED_FLAG_SYMBOL))
 	    processing_gcc_compilation = 1;
-	  else if (STREQ (namestring, GCC2_COMPILED_FLAG_SYMBOL))
+	  else if (DEPRECATED_STREQ (namestring, GCC2_COMPILED_FLAG_SYMBOL))
 	    processing_gcc_compilation = 2;
 
 #if 0
Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.133
diff -u -r1.133 defs.h
--- defs.h	31 Oct 2003 19:19:51 -0000	1.133
+++ defs.h	23 Nov 2003 20:10:40 -0000
@@ -154,8 +154,14 @@
    issue is found that we spend the effort on algorithmic
    optimizations than micro-optimizing.'' J.T. */
 
-#define STREQ(a,b) (*(a) == *(b) ? !strcmp ((a), (b)) : 0)
-#define STREQN(a,b,c) (*(a) == *(b) ? !strncmp ((a), (b), (c)) : 0)
+/* NOTE: cagney/2003-11-23: All instances of STREQ[N] covered by
+   testing GDB on a stabs system have been replaced by equivalent
+   str[n]cmp calls.  To avoid the possability of introducing bugs when
+   making untested changes, the remaining references were deprecated
+   rather than replaced.  */
+
+#define DEPRECATED_STREQ(a,b) (*(a) == *(b) ? !strcmp ((a), (b)) : 0)
+#define DEPRECATED_STREQN(a,b,c) (*(a) == *(b) ? !strncmp ((a), (b), (c)) : 0)
 
 /* Check if a character is one of the commonly used C++ marker characters.  */
 extern int is_cplus_marker (int);
Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.114
diff -u -r1.114 dwarf2read.c
--- dwarf2read.c	19 Nov 2003 15:08:01 -0000	1.114
+++ dwarf2read.c	23 Nov 2003 20:11:24 -0000
@@ -2659,7 +2659,7 @@
   /* Look up member function name in fieldlist.  */
   for (i = 0; i < fip->nfnfields; i++)
     {
-      if (STREQ (fip->fnfieldlists[i].name, fieldname))
+      if (DEPRECATED_STREQ (fip->fnfieldlists[i].name, fieldname))
 	break;
     }
 
@@ -2938,7 +2938,7 @@
 		    {
 		      char *fieldname = TYPE_FIELD_NAME (t, i);
 
-		      if (STREQN (fieldname, vptr_name, strlen (vptr_name) - 1)
+		      if (DEPRECATED_STREQN (fieldname, vptr_name, strlen (vptr_name) - 1)
 			  && is_cplus_marker (fieldname[strlen (vptr_name)]))
 			{
 			  TYPE_VPTR_FIELDNO (type) = i;
Index: dwarfread.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarfread.c,v
retrieving revision 1.31
diff -u -r1.31 dwarfread.c
--- dwarfread.c	6 Nov 2003 22:54:01 -0000	1.31
+++ dwarfread.c	23 Nov 2003 20:11:46 -0000
@@ -1802,7 +1802,7 @@
   /* If this compilation unit was compiled with g++ or gcc, then set the
      processing_gcc_compilation flag. */
 
-  if (STREQN (producer, GCC_PRODUCER, strlen (GCC_PRODUCER)))
+  if (DEPRECATED_STREQN (producer, GCC_PRODUCER, strlen (GCC_PRODUCER)))
     {
       char version = producer[strlen (GCC_PRODUCER)];
       processing_gcc_compilation = (version == '2' ? 2 : 1);
@@ -1820,7 +1820,7 @@
 
   if (AUTO_DEMANGLING)
     {
-      if (STREQN (producer, GPLUS_PRODUCER, strlen (GPLUS_PRODUCER)))
+      if (DEPRECATED_STREQN (producer, GPLUS_PRODUCER, strlen (GPLUS_PRODUCER)))
 	{
 #if 0
 	  /* For now, stay with AUTO_DEMANGLING for g++ output, as we don't
@@ -1828,7 +1828,7 @@
 	  set_demangling_style (GNU_DEMANGLING_STYLE_STRING);
 #endif
 	}
-      else if (STREQN (producer, LCC_PRODUCER, strlen (LCC_PRODUCER)))
+      else if (DEPRECATED_STREQN (producer, LCC_PRODUCER, strlen (LCC_PRODUCER)))
 	{
 	  set_demangling_style (LUCID_DEMANGLING_STYLE_STRING);
 	}
Index: environ.c
===================================================================
RCS file: /cvs/src/src/gdb/environ.c,v
retrieving revision 1.9
diff -u -r1.9 environ.c
--- environ.c	6 Nov 2003 22:54:01 -0000	1.9
+++ environ.c	23 Nov 2003 20:11:46 -0000
@@ -170,7 +170,7 @@
 
   for (; (s = *vector) != NULL; vector++)
     {
-      if (STREQN (s, var, len) && s[len] == '=')
+      if (DEPRECATED_STREQN (s, var, len) && s[len] == '=')
 	{
 	  xfree (s);
 	  /* Walk through the vector, shuffling args down by one, including
Index: eval.c
===================================================================
RCS file: /cvs/src/src/gdb/eval.c,v
retrieving revision 1.38
diff -u -r1.38 eval.c
--- eval.c	25 Sep 2003 16:39:38 -0000	1.38
+++ eval.c	23 Nov 2003 20:12:00 -0000
@@ -227,7 +227,7 @@
 		   fieldno++)
 		{
 		  char *field_name = TYPE_FIELD_NAME (struct_type, fieldno);
-		  if (field_name != NULL && STREQ (field_name, label))
+		  if (field_name != NULL && DEPRECATED_STREQ (field_name, label))
 		    {
 		      variantno = -1;
 		      subfieldno = fieldno;
@@ -255,7 +255,7 @@
 				 subfieldno < TYPE_NFIELDS (substruct_type);
 				   subfieldno++)
 				{
-				  if (STREQ (TYPE_FIELD_NAME (substruct_type,
+				  if (DEPRECATED_STREQ (TYPE_FIELD_NAME (substruct_type,
 							      subfieldno),
 					     label))
 				    {
Index: exec.c
===================================================================
RCS file: /cvs/src/src/gdb/exec.c,v
retrieving revision 1.34
diff -u -r1.34 exec.c
--- exec.c	6 Nov 2003 02:52:27 -0000	1.34
+++ exec.c	23 Nov 2003 20:12:07 -0000
@@ -384,14 +384,14 @@
   if ((bfd_get_section_flags (abfd, sect) & SEC_LOAD) == 0)
     return;
 
-  if (STREQ (bfd_section_name (abfd, sect), ".text"))
+  if (DEPRECATED_STREQ (bfd_section_name (abfd, sect), ".text"))
     {
       vp->tstart = bfd_section_vma (abfd, sect);
       vp->tend = vp->tstart + bfd_section_size (abfd, sect);
       vp->tvma = bfd_section_vma (abfd, sect);
       vp->toffs = sect->filepos;
     }
-  else if (STREQ (bfd_section_name (abfd, sect), ".data"))
+  else if (DEPRECATED_STREQ (bfd_section_name (abfd, sect), ".data"))
     {
       vp->dstart = bfd_section_vma (abfd, sect);
       vp->dend = vp->dstart + bfd_section_size (abfd, sect);
Index: f-lang.c
===================================================================
RCS file: /cvs/src/src/gdb/f-lang.c,v
retrieving revision 1.19
diff -u -r1.19 f-lang.c
--- f-lang.c	8 Nov 2003 00:13:02 -0000	1.19
+++ f-lang.c	23 Nov 2003 20:12:15 -0000
@@ -799,7 +799,8 @@
 
   while (tmp != NULL)
     {
-      if (STREQ (tmp->name, name) && STREQ (tmp->owning_function, funcname))
+      if (DEPRECATED_STREQ (tmp->name, name)
+	  && DEPRECATED_STREQ (tmp->owning_function, funcname))
 	return (tmp);
       else
 	tmp = tmp->next;
Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.106
diff -u -r1.106 hppa-tdep.c
--- hppa-tdep.c	22 Nov 2003 22:15:23 -0000	1.106
+++ hppa-tdep.c	23 Nov 2003 20:12:52 -0000
@@ -3379,7 +3379,7 @@
 	  ALL_MSYMBOLS (objfile, msymbol)
 	  {
 	    if (MSYMBOL_TYPE (msymbol) == mst_text
-		&& STREQ (DEPRECATED_SYMBOL_NAME (msymbol), DEPRECATED_SYMBOL_NAME (msym)))
+		&& DEPRECATED_STREQ (DEPRECATED_SYMBOL_NAME (msymbol), DEPRECATED_SYMBOL_NAME (msym)))
 	      {
 		function_found = 1;
 		break;
Index: hpread.c
===================================================================
RCS file: /cvs/src/src/gdb/hpread.c,v
retrieving revision 1.40
diff -u -r1.40 hpread.c
--- hpread.c	14 Sep 2003 16:32:12 -0000	1.40
+++ hpread.c	23 Nov 2003 20:13:43 -0000
@@ -3897,7 +3897,7 @@
 	      fn_p = fn_list;
 	      while (fn_p)
 		{
-		  if (STREQ (fn_p->field.name, method_name))
+		  if (DEPRECATED_STREQ (fn_p->field.name, method_name))
 		    break;
 		  fn_p = fn_p->next;
 		}
@@ -6303,7 +6303,7 @@
       /* Do we have another anonymous union? If so, adjust the bitoffsets
          of its members and skip over its members. */
       if ((TYPE_CODE (anon_type) == TYPE_CODE_UNION) &&
-	  (!name || STREQ (name, "")))
+	  (!name || DEPRECATED_STREQ (name, "")))
 	{
 	  hpread_adjust_bitoffsets (anon_type, bitoffset);
 	  field = hpread_get_next_skip_over_anon_unions (TYPE_NFIELDS (anon_type), field, fieldp, objfile);
Index: jv-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/jv-exp.y,v
retrieving revision 1.17
diff -u -r1.17 jv-exp.y
--- jv-exp.y	6 Nov 2003 22:54:01 -0000	1.17
+++ jv-exp.y	23 Nov 2003 20:13:50 -0000
@@ -1133,34 +1133,34 @@
   switch (namelen)
     {
     case 7:
-      if (STREQN (tokstart, "boolean", 7))
+      if (DEPRECATED_STREQN (tokstart, "boolean", 7))
 	return BOOLEAN;
       break;
     case 6:
-      if (STREQN (tokstart, "double", 6))      
+      if (DEPRECATED_STREQN (tokstart, "double", 6))      
 	return DOUBLE;
       break;
     case 5:
-      if (STREQN (tokstart, "short", 5))
+      if (DEPRECATED_STREQN (tokstart, "short", 5))
 	return SHORT;
-      if (STREQN (tokstart, "false", 5))
+      if (DEPRECATED_STREQN (tokstart, "false", 5))
 	{
 	  yylval.lval = 0;
 	  return BOOLEAN_LITERAL;
 	}
-      if (STREQN (tokstart, "super", 5))
+      if (DEPRECATED_STREQN (tokstart, "super", 5))
 	return SUPER;
-      if (STREQN (tokstart, "float", 5))
+      if (DEPRECATED_STREQN (tokstart, "float", 5))
 	return FLOAT;
       break;
     case 4:
-      if (STREQN (tokstart, "long", 4))
+      if (DEPRECATED_STREQN (tokstart, "long", 4))
 	return LONG;
-      if (STREQN (tokstart, "byte", 4))
+      if (DEPRECATED_STREQN (tokstart, "byte", 4))
 	return BYTE;
-      if (STREQN (tokstart, "char", 4))
+      if (DEPRECATED_STREQN (tokstart, "char", 4))
 	return CHAR;
-      if (STREQN (tokstart, "true", 4))
+      if (DEPRECATED_STREQN (tokstart, "true", 4))
 	{
 	  yylval.lval = 1;
 	  return BOOLEAN_LITERAL;
Index: language.c
===================================================================
RCS file: /cvs/src/src/gdb/language.c,v
retrieving revision 1.41
diff -u -r1.41 language.c
--- language.c	8 Nov 2003 00:13:02 -0000	1.41
+++ language.c	23 Nov 2003 20:13:58 -0000
@@ -344,17 +344,17 @@
 static void
 set_case_command (char *ignore, int from_tty)
 {
-   if (STREQ (case_sensitive, "on"))
+   if (DEPRECATED_STREQ (case_sensitive, "on"))
    {
       case_sensitivity = case_sensitive_on;
       case_mode = case_mode_manual;
    }
-   else if (STREQ (case_sensitive, "off"))
+   else if (DEPRECATED_STREQ (case_sensitive, "off"))
    {
       case_sensitivity = case_sensitive_off;
       case_mode = case_mode_manual;
    }
-   else if (STREQ (case_sensitive, "auto"))
+   else if (DEPRECATED_STREQ (case_sensitive, "auto"))
    {
       case_mode = case_mode_auto;
       set_type_range_case ();
@@ -1059,7 +1059,7 @@
   int i;
 
   for (i = 0; i < languages_size; i++)
-    if (STREQ (languages[i]->la_name, str))
+    if (DEPRECATED_STREQ (languages[i]->la_name, str))
       return languages[i]->la_language;
 
   return language_unknown;
Index: m2-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/m2-exp.y,v
retrieving revision 1.11
diff -u -r1.11 m2-exp.y
--- m2-exp.y	25 Sep 2003 16:50:38 -0000	1.11
+++ m2-exp.y	23 Nov 2003 20:14:05 -0000
@@ -835,7 +835,7 @@
 
   /* See if it is a special token of length 2 */
   for( i = 0 ; i < (int) (sizeof tokentab2 / sizeof tokentab2[0]) ; i++)
-     if(STREQN(tokentab2[i].name, tokstart, 2))
+     if(DEPRECATED_STREQN(tokentab2[i].name, tokstart, 2))
      {
 	lexptr += 2;
 	return tokentab2[i].token;
@@ -992,7 +992,7 @@
 
   /*  Lookup special keywords */
   for(i = 0 ; i < (int) (sizeof(keytab) / sizeof(keytab[0])) ; i++)
-     if(namelen == strlen(keytab[i].keyw) && STREQN(tokstart,keytab[i].keyw,namelen))
+     if(namelen == strlen(keytab[i].keyw) && DEPRECATED_STREQN(tokstart,keytab[i].keyw,namelen))
 	   return keytab[i].token;
 
   yylval.sval.ptr = tokstart;
@@ -1066,12 +1066,12 @@
     else
     {
        /* Built-in BOOLEAN type.  This is sort of a hack. */
-       if(STREQN(tokstart,"TRUE",4))
+       if(DEPRECATED_STREQN(tokstart,"TRUE",4))
        {
 	  yylval.ulval = 1;
 	  return M2_TRUE;
        }
-       else if(STREQN(tokstart,"FALSE",5))
+       else if(DEPRECATED_STREQN(tokstart,"FALSE",5))
        {
 	  yylval.ulval = 0;
 	  return M2_FALSE;
Index: mcore-rom.c
===================================================================
RCS file: /cvs/src/src/gdb/mcore-rom.c,v
retrieving revision 1.5
diff -u -r1.5 mcore-rom.c
--- mcore-rom.c	10 Jul 2001 23:08:12 -0000	1.5
+++ mcore-rom.c	23 Nov 2003 20:14:05 -0000
@@ -102,7 +102,7 @@
       if (strchr (p, '-'))
 	{
 	  /* got a range. either r0-r7, r8-r15 or ss0-ss4 */
-	  if (STREQN (p, "r0", 2) || STREQN (p, "r8", 2))
+	  if (DEPRECATED_STREQN (p, "r0", 2) || DEPRECATED_STREQN (p, "r8", 2))
 	    {
 	      int rn = (p[1] == '0' ? 0 : 8);
 	      int i = 0;
@@ -116,7 +116,7 @@
 		  i++;
 		}
 	    }
-	  else if (STREQN (p, "ss", 2))
+	  else if (DEPRECATED_STREQN (p, "ss", 2))
 	    {
 	      /* get the next five values, ignoring the first */
 	      int rn;
@@ -145,7 +145,7 @@
 	    {
 	      for (i = 0; i < NUM_REGS; i++)
 		{
-		  if (picobug_regnames[i] && STREQ (picobug_regnames[i], name))
+		  if (picobug_regnames[i] && DEPRECATED_STREQ (picobug_regnames[i], name))
 		    break;
 		}
 
Index: mdebugread.c
===================================================================
RCS file: /cvs/src/src/gdb/mdebugread.c,v
retrieving revision 1.53
diff -u -r1.53 mdebugread.c
--- mdebugread.c	8 Nov 2003 00:13:02 -0000	1.53
+++ mdebugread.c	23 Nov 2003 20:14:41 -0000
@@ -793,7 +793,7 @@
       else
 	{
 	  t = parse_type (cur_fd, ax, sh->index + 1, 0, bigend, name);
-	  if (STREQ (name, "malloc") && TYPE_CODE (t) == TYPE_CODE_VOID)
+	  if (DEPRECATED_STREQ (name, "malloc") && TYPE_CODE (t) == TYPE_CODE_VOID)
 	    {
 	      /* I don't know why, but, at least under Alpha GNU/Linux,
 	         when linking against a malloc without debugging
@@ -1667,7 +1667,7 @@
 	      bad_tag_guess_complaint (sym_name);
 	      TYPE_CODE (tp) = type_code;
 	    }
-	  if (TYPE_NAME (tp) == NULL || !STREQ (TYPE_NAME (tp), name))
+	  if (TYPE_NAME (tp) == NULL || !DEPRECATED_STREQ (TYPE_NAME (tp), name))
 	    TYPE_NAME (tp) = obsavestring (name, strlen (name),
 					   &current_objfile->type_obstack);
 	}
@@ -1987,7 +1987,7 @@
 
       /* Correct incorrect setjmp procedure descriptor from the library
          to make backtrace through setjmp work.  */
-      if (e->pdr.pcreg == 0 && STREQ (sh_name, "setjmp"))
+      if (e->pdr.pcreg == 0 && DEPRECATED_STREQ (sh_name, "setjmp"))
 	{
 	  complaint (&symfile_complaints, "fixing bad setjmp PDR from libc");
 	  e->pdr.pcreg = RA_REGNUM;
@@ -2608,7 +2608,7 @@
 			  ((char *) debug_info->external_sym
 			   + (fh->isymBase + 1) * external_sym_size),
 			  &sh);
-	  if (STREQ (debug_info->ss + fh->issBase + sh.iss, stabs_symbol))
+	  if (DEPRECATED_STREQ (debug_info->ss + fh->issBase + sh.iss, stabs_symbol))
 	    processing_gcc_compilation = 2;
 	}
 
@@ -2929,12 +2929,12 @@
 			 things like "break c-exp.y:435" need to work (I
 			 suppose the psymtab_include_list could be hashed or put
 			 in a binary tree, if profiling shows this is a major hog).  */
-		      if (pst && STREQ (namestring, pst->filename))
+		      if (pst && DEPRECATED_STREQ (namestring, pst->filename))
 			continue;
 		      {
 			int i;
 			for (i = 0; i < includes_used; i++)
-			  if (STREQ (namestring, psymtab_include_list[i]))
+			  if (DEPRECATED_STREQ (namestring, psymtab_include_list[i]))
 			    {
 			      i = -1;
 			      break;
@@ -3861,7 +3861,7 @@
 		      ((char *) debug_info->external_sym
 		       + (fh->isymBase + 1) * external_sym_size),
 		      &sh);
-      if (STREQ (debug_info->ss + fh->issBase + sh.iss,
+      if (DEPRECATED_STREQ (debug_info->ss + fh->issBase + sh.iss,
 		 stabs_symbol))
 	{
 	  /* We indicate that this is a GCC compilation so that certain
Index: mipsread.c
===================================================================
RCS file: /cvs/src/src/gdb/mipsread.c,v
retrieving revision 1.13
diff -u -r1.13 mipsread.c
--- mipsread.c	14 Sep 2003 16:32:13 -0000	1.13
+++ mipsread.c	23 Nov 2003 20:14:49 -0000
@@ -197,19 +197,19 @@
 
   si = (struct alphacoff_dynsecinfo *) sip;
 
-  if (STREQ (sectp->name, ".dynsym"))
+  if (DEPRECATED_STREQ (sectp->name, ".dynsym"))
     {
       si->sym_sect = sectp;
     }
-  else if (STREQ (sectp->name, ".dynstr"))
+  else if (DEPRECATED_STREQ (sectp->name, ".dynstr"))
     {
       si->str_sect = sectp;
     }
-  else if (STREQ (sectp->name, ".dynamic"))
+  else if (DEPRECATED_STREQ (sectp->name, ".dynamic"))
     {
       si->dyninfo_sect = sectp;
     }
-  else if (STREQ (sectp->name, ".got"))
+  else if (DEPRECATED_STREQ (sectp->name, ".got"))
     {
       si->got_sect = sectp;
     }
Index: objc-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/objc-exp.y,v
retrieving revision 1.15
diff -u -r1.15 objc-exp.y
--- objc-exp.y	6 Nov 2003 22:54:01 -0000	1.15
+++ objc-exp.y	23 Nov 2003 20:15:03 -0000
@@ -680,7 +680,7 @@
 			    error ("`%s' is not defined as an aggregate type.",
 				   TYPE_NAME (type));
 
-			  if (!STREQ (type_name_no_tag (type), $4.ptr))
+			  if (!DEPRECATED_STREQ (type_name_no_tag (type), $4.ptr))
 			    error ("invalid destructor `%s::~%s'",
 				   type_name_no_tag (type), $4.ptr);
 
@@ -1265,7 +1265,7 @@
   tokstart = lexptr;
   /* See if it is a special token of length 3.  */
   for (i = 0; i < sizeof tokentab3 / sizeof tokentab3[0]; i++)
-    if (STREQN (tokstart, tokentab3[i].operator, 3))
+    if (DEPRECATED_STREQN (tokstart, tokentab3[i].operator, 3))
       {
 	lexptr += 3;
 	yylval.opcode = tokentab3[i].opcode;
@@ -1274,7 +1274,7 @@
 
   /* See if it is a special token of length 2.  */
   for (i = 0; i < sizeof tokentab2 / sizeof tokentab2[0]; i++)
-    if (STREQN (tokstart, tokentab2[i].operator, 2))
+    if (DEPRECATED_STREQN (tokstart, tokentab2[i].operator, 2))
       {
 	lexptr += 2;
 	yylval.opcode = tokentab2[i].opcode;
@@ -1589,43 +1589,43 @@
   switch (namelen)
     {
     case 8:
-      if (STREQN (tokstart, "unsigned", 8))
+      if (DEPRECATED_STREQN (tokstart, "unsigned", 8))
 	return UNSIGNED;
       if (current_language->la_language == language_cplus
 	  && strncmp (tokstart, "template", 8) == 0)
 	return TEMPLATE;
-      if (STREQN (tokstart, "volatile", 8))
+      if (DEPRECATED_STREQN (tokstart, "volatile", 8))
 	return VOLATILE_KEYWORD;
       break;
     case 6:
-      if (STREQN (tokstart, "struct", 6))
+      if (DEPRECATED_STREQN (tokstart, "struct", 6))
 	return STRUCT;
-      if (STREQN (tokstart, "signed", 6))
+      if (DEPRECATED_STREQN (tokstart, "signed", 6))
 	return SIGNED_KEYWORD;
-      if (STREQN (tokstart, "sizeof", 6))      
+      if (DEPRECATED_STREQN (tokstart, "sizeof", 6))      
 	return SIZEOF;
-      if (STREQN (tokstart, "double", 6))      
+      if (DEPRECATED_STREQN (tokstart, "double", 6))      
 	return DOUBLE_KEYWORD;
       break;
     case 5:
       if ((current_language->la_language == language_cplus)
 	  && strncmp (tokstart, "class", 5) == 0)
 	return CLASS;
-      if (STREQN (tokstart, "union", 5))
+      if (DEPRECATED_STREQN (tokstart, "union", 5))
 	return UNION;
-      if (STREQN (tokstart, "short", 5))
+      if (DEPRECATED_STREQN (tokstart, "short", 5))
 	return SHORT;
-      if (STREQN (tokstart, "const", 5))
+      if (DEPRECATED_STREQN (tokstart, "const", 5))
 	return CONST_KEYWORD;
       break;
     case 4:
-      if (STREQN (tokstart, "enum", 4))
+      if (DEPRECATED_STREQN (tokstart, "enum", 4))
 	return ENUM;
-      if (STREQN (tokstart, "long", 4))
+      if (DEPRECATED_STREQN (tokstart, "long", 4))
 	return LONG;
       break;
     case 3:
-      if (STREQN (tokstart, "int", 3))
+      if (DEPRECATED_STREQN (tokstart, "int", 3))
 	return INT_KEYWORD;
       break;
     default:
Index: objfiles.c
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.c,v
retrieving revision 1.42
diff -u -r1.42 objfiles.c
--- objfiles.c	11 Nov 2003 20:04:52 -0000	1.42
+++ objfiles.c	23 Nov 2003 20:15:10 -0000
@@ -1104,7 +1104,7 @@
     return 0;
 
   for (i = 0; i < objfile->import_list_size; i++)
-    if (objfile->import_list[i] && STREQ (name, objfile->import_list[i]))
+    if (objfile->import_list[i] && DEPRECATED_STREQ (name, objfile->import_list[i]))
       return 1;
   return 0;
 }
Index: p-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/p-exp.y,v
retrieving revision 1.25
diff -u -r1.25 p-exp.y
--- p-exp.y	25 Sep 2003 16:50:38 -0000	1.25
+++ p-exp.y	23 Nov 2003 20:15:17 -0000
@@ -1369,29 +1369,29 @@
   switch (namelen)
     {
     case 6:
-      if (STREQ (uptokstart, "OBJECT"))
+      if (DEPRECATED_STREQ (uptokstart, "OBJECT"))
 	return CLASS;
-      if (STREQ (uptokstart, "RECORD"))
+      if (DEPRECATED_STREQ (uptokstart, "RECORD"))
 	return STRUCT;
-      if (STREQ (uptokstart, "SIZEOF"))
+      if (DEPRECATED_STREQ (uptokstart, "SIZEOF"))
 	return SIZEOF;
       break;
     case 5:
-      if (STREQ (uptokstart, "CLASS"))
+      if (DEPRECATED_STREQ (uptokstart, "CLASS"))
 	return CLASS;
-      if (STREQ (uptokstart, "FALSE"))
+      if (DEPRECATED_STREQ (uptokstart, "FALSE"))
 	{
           yylval.lval = 0;
           return FALSEKEYWORD;
         }
       break;
     case 4:
-      if (STREQ (uptokstart, "TRUE"))
+      if (DEPRECATED_STREQ (uptokstart, "TRUE"))
 	{
           yylval.lval = 1;
   	  return TRUEKEYWORD;
         }
-      if (STREQ (uptokstart, "SELF"))
+      if (DEPRECATED_STREQ (uptokstart, "SELF"))
         {
           /* here we search for 'this' like
              inserted in FPC stabs debug info */
Index: p-typeprint.c
===================================================================
RCS file: /cvs/src/src/gdb/p-typeprint.c,v
retrieving revision 1.12
diff -u -r1.12 p-typeprint.c
--- p-typeprint.c	14 Sep 2003 16:32:13 -0000	1.12
+++ p-typeprint.c	23 Nov 2003 20:15:25 -0000
@@ -139,8 +139,8 @@
 pascal_type_print_method_args (char *physname, char *methodname,
 			       struct ui_file *stream)
 {
-  int is_constructor = STREQN (physname, "__ct__", 6);
-  int is_destructor = STREQN (physname, "__dt__", 6);
+  int is_constructor = DEPRECATED_STREQN (physname, "__ct__", 6);
+  int is_destructor = DEPRECATED_STREQN (physname, "__dt__", 6);
 
   if (is_constructor || is_destructor)
     {
@@ -559,7 +559,7 @@
 	    {
 	      QUIT;
 	      /* Don't print out virtual function table.  */
-	      if (STREQN (TYPE_FIELD_NAME (type, i), "_vptr", 5)
+	      if (DEPRECATED_STREQN (TYPE_FIELD_NAME (type, i), "_vptr", 5)
 		  && is_cplus_marker ((TYPE_FIELD_NAME (type, i))[5]))
 		continue;
 
@@ -637,8 +637,8 @@
 		{
 		  char *physname = TYPE_FN_FIELD_PHYSNAME (f, j);
 
-		  int is_constructor = STREQN (physname, "__ct__", 6);
-		  int is_destructor = STREQN (physname, "__dt__", 6);
+		  int is_constructor = DEPRECATED_STREQN (physname, "__ct__", 6);
+		  int is_destructor = DEPRECATED_STREQN (physname, "__dt__", 6);
 
 		  QUIT;
 		  if (TYPE_FN_FIELD_PROTECTED (f, j))
Index: p-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/p-valprint.c,v
retrieving revision 1.24
diff -u -r1.24 p-valprint.c
--- p-valprint.c	8 Nov 2003 00:13:02 -0000	1.24
+++ p-valprint.c	23 Nov 2003 20:15:32 -0000
@@ -650,7 +650,7 @@
 	  check_stub_method_group (domain, i);
 	  for (j = 0; j < len2; j++)
 	    {
-	      if (STREQ (DEPRECATED_SYMBOL_NAME (sym), TYPE_FN_FIELD_PHYSNAME (f, j)))
+	      if (DEPRECATED_STREQ (DEPRECATED_SYMBOL_NAME (sym), TYPE_FN_FIELD_PHYSNAME (f, j)))
 		goto common;
 	    }
 	}
Index: rs6000-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-nat.c,v
retrieving revision 1.36
diff -u -r1.36 rs6000-nat.c
--- rs6000-nat.c	6 Nov 2003 02:52:27 -0000	1.36
+++ rs6000-nat.c	23 Nov 2003 20:15:39 -0000
@@ -759,7 +759,7 @@
       last = 0;
       /* FIXME??? am I tossing BFDs?  bfd? */
       while ((last = bfd_openr_next_archived_file (abfd, last)))
-	if (STREQ (mem, last->filename))
+	if (DEPRECATED_STREQ (mem, last->filename))
 	  break;
 
       if (!last)
@@ -843,8 +843,8 @@
 
 	  /* The filenames are not always sufficient to match on. */
 
-	  if ((name[0] == '/' && !STREQ (name, vp->name))
-	      || (memb[0] && !STREQ (memb, vp->member)))
+	  if ((name[0] == '/' && !DEPRECATED_STREQ (name, vp->name))
+	      || (memb[0] && !DEPRECATED_STREQ (memb, vp->member)))
 	    continue;
 
 	  /* See if we are referring to the same file.
@@ -941,17 +941,17 @@
 
   for (i = 0; &exec_ops.to_sections[i] < exec_ops.to_sections_end; i++)
     {
-      if (STREQ (".text", exec_ops.to_sections[i].the_bfd_section->name))
+      if (DEPRECATED_STREQ (".text", exec_ops.to_sections[i].the_bfd_section->name))
 	{
 	  exec_ops.to_sections[i].addr += vmap->tstart - vmap->tvma;
 	  exec_ops.to_sections[i].endaddr += vmap->tstart - vmap->tvma;
 	}
-      else if (STREQ (".data", exec_ops.to_sections[i].the_bfd_section->name))
+      else if (DEPRECATED_STREQ (".data", exec_ops.to_sections[i].the_bfd_section->name))
 	{
 	  exec_ops.to_sections[i].addr += vmap->dstart - vmap->dvma;
 	  exec_ops.to_sections[i].endaddr += vmap->dstart - vmap->dvma;
 	}
-      else if (STREQ (".bss", exec_ops.to_sections[i].the_bfd_section->name))
+      else if (DEPRECATED_STREQ (".bss", exec_ops.to_sections[i].the_bfd_section->name))
 	{
 	  exec_ops.to_sections[i].addr += vmap->dstart - vmap->dvma;
 	  exec_ops.to_sections[i].endaddr += vmap->dstart - vmap->dvma;
Index: source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.46
diff -u -r1.46 source.c
--- source.c	21 Sep 2003 01:26:45 -0000	1.46
+++ source.c	23 Nov 2003 20:15:54 -0000
@@ -260,7 +260,7 @@
 	{
 	  char *name = s->filename;
 	  int len = strlen (name);
-	  if (!(len > 2 && (STREQ (&name[len - 2], ".h"))))
+	  if (!(len > 2 && (DEPRECATED_STREQ (&name[len - 2], ".h"))))
 	    {
 	      current_source_symtab = s;
 	    }
@@ -277,7 +277,7 @@
 	{
 	  char *name = ps->filename;
 	  int len = strlen (name);
-	  if (!(len > 2 && (STREQ (&name[len - 2], ".h"))))
+	  if (!(len > 2 && (DEPRECATED_STREQ (&name[len - 2], ".h"))))
 	    {
 	      cs_pst = ps;
 	    }
Index: sparc-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparc-tdep.c,v
retrieving revision 1.133
diff -u -r1.133 sparc-tdep.c
--- sparc-tdep.c	6 Oct 2003 19:27:12 -0000	1.133
+++ sparc-tdep.c	23 Nov 2003 20:16:54 -0000
@@ -433,7 +433,7 @@
          as the third parameter.  The offset to the saved pc is 12.  */
       find_pc_partial_function (get_frame_pc (frame), &name,
 				(CORE_ADDR *) NULL, (CORE_ADDR *) NULL);
-      if (name && STREQ (name, "ucbsigvechandler"))
+      if (name && DEPRECATED_STREQ (name, "ucbsigvechandler"))
 	saved_pc_offset = 12;
 
       /* The sigcontext address is contained in register O2.  */
Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.96
diff -u -r1.96 stack.c
--- stack.c	19 Nov 2003 16:27:56 -0000	1.96
+++ stack.c	23 Nov 2003 20:17:08 -0000
@@ -1356,7 +1356,7 @@
 
   ALL_BLOCK_SYMBOLS (b, iter, sym)
     {
-      if (STREQ (DEPRECATED_SYMBOL_NAME (sym), "default"))
+      if (DEPRECATED_STREQ (DEPRECATED_SYMBOL_NAME (sym), "default"))
 	{
 	  if (*have_default)
 	    continue;
Index: target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.66
diff -u -r1.66 target.c
--- target.c	10 Nov 2003 21:20:44 -0000	1.66
+++ target.c	23 Nov 2003 20:17:22 -0000
@@ -1284,7 +1284,7 @@
 void
 target_link (char *modname, CORE_ADDR *t_reloc)
 {
-  if (STREQ (current_target.to_shortname, "rombug"))
+  if (DEPRECATED_STREQ (current_target.to_shortname, "rombug"))
     {
       (current_target.to_lookup_symbol) (modname, t_reloc);
       if (*t_reloc == 0)
Index: xcoffread.c
===================================================================
RCS file: /cvs/src/src/gdb/xcoffread.c,v
retrieving revision 1.36
diff -u -r1.36 xcoffread.c
--- xcoffread.c	6 Nov 2003 02:52:28 -0000	1.36
+++ xcoffread.c	23 Nov 2003 20:17:46 -0000
@@ -1251,7 +1251,7 @@
 	  break;
 
 	case C_FCN:
-	  if (STREQ (cs->c_name, ".bf"))
+	  if (DEPRECATED_STREQ (cs->c_name, ".bf"))
 	    {
 	      CORE_ADDR off = ANOFFSET (objfile->section_offsets,
 					SECT_OFF_TEXT (objfile));
@@ -1268,7 +1268,7 @@
 	      if (new->name != NULL)
 		SYMBOL_SECTION (new->name) = SECT_OFF_TEXT (objfile);
 	    }
-	  else if (STREQ (cs->c_name, ".ef"))
+	  else if (DEPRECATED_STREQ (cs->c_name, ".ef"))
 	    {
 
 	      bfd_coff_swap_aux_in (abfd, raw_auxptr, cs->c_type, cs->c_sclass,
@@ -1362,7 +1362,7 @@
 	  break;
 
 	case C_BLOCK:
-	  if (STREQ (cs->c_name, ".bb"))
+	  if (DEPRECATED_STREQ (cs->c_name, ".bb"))
 	    {
 	      depth++;
 	      new = push_context (depth,
@@ -1370,7 +1370,7 @@
 				   + ANOFFSET (objfile->section_offsets,
 					       SECT_OFF_TEXT (objfile))));
 	    }
-	  else if (STREQ (cs->c_name, ".eb"))
+	  else if (DEPRECATED_STREQ (cs->c_name, ".eb"))
 	    {
 	      if (context_stack_depth <= 0)
 		{		/* We attempted to pop an empty context stack */
@@ -1671,7 +1671,7 @@
       if (symbol->n_sclass == C_FCN)
 	{
 	  char *name = xcoff64 ? strtbl + symbol->n_offset : symbol->n_name;
-	  if (STREQ (name, ".bf"))
+	  if (DEPRECATED_STREQ (name, ".bf"))
 	    goto gotit;
 	}
       symno += symbol->n_numaux + 1;
@@ -1705,7 +1705,7 @@
 
   count = asect->lineno_count;
 
-  if (!STREQ (asect->name, ".text") || count == 0)
+  if (!DEPRECATED_STREQ (asect->name, ".text") || count == 0)
     return;
 
   size = count * coff_data (abfd)->local_linesz;
@@ -2530,12 +2530,12 @@
 	       things like "break c-exp.y:435" need to work (I
 	       suppose the psymtab_include_list could be hashed or put
 	       in a binary tree, if profiling shows this is a major hog).  */
-	    if (pst && STREQ (namestring, pst->filename))
+	    if (pst && DEPRECATED_STREQ (namestring, pst->filename))
 	      continue;
 	    {
 	      int i;
 	      for (i = 0; i < includes_used; i++)
-		if (STREQ (namestring, psymtab_include_list[i]))
+		if (DEPRECATED_STREQ (namestring, psymtab_include_list[i]))
 		  {
 		    i = -1;
 		    break;
Index: config/mips/tm-irix5.h
===================================================================
RCS file: /cvs/src/src/gdb/config/mips/tm-irix5.h,v
retrieving revision 1.18
diff -u -r1.18 tm-irix5.h
--- config/mips/tm-irix5.h	22 Nov 2003 22:32:28 -0000	1.18
+++ config/mips/tm-irix5.h	23 Nov 2003 20:17:46 -0000
@@ -31,7 +31,7 @@
 
 /* The signal handler trampoline is called _sigtramp.  */
 #undef IN_SIGTRAMP
-#define IN_SIGTRAMP(pc, name) ((name) && STREQ ("_sigtramp", name))
+#define IN_SIGTRAMP(pc, name) ((name) && DEPRECATED_STREQ ("_sigtramp", name))
 
 /* Irix 5 saves a full 64 bits for each register.  We skip 2 * 4 to
    get to the saved PC (the register mask and status register are both
Index: config/mips/tm-irix6.h
===================================================================
RCS file: /cvs/src/src/gdb/config/mips/tm-irix6.h,v
retrieving revision 1.22
diff -u -r1.22 tm-irix6.h
--- config/mips/tm-irix6.h	22 Nov 2003 22:32:28 -0000	1.22
+++ config/mips/tm-irix6.h	23 Nov 2003 20:17:46 -0000
@@ -24,7 +24,7 @@
 
 /* The signal handler trampoline is called _sigtramp.  */
 #undef IN_SIGTRAMP
-#define IN_SIGTRAMP(pc, name) ((name) && STREQ ("_sigtramp", name))
+#define IN_SIGTRAMP(pc, name) ((name) && DEPRECATED_STREQ ("_sigtramp", name))
 
 /* Offsets for register values in _sigtramp frame.
    sigcontext is immediately above the _sigtramp frame on Irix.  */
Index: config/mips/tm-mipsv4.h
===================================================================
RCS file: /cvs/src/src/gdb/config/mips/tm-mipsv4.h,v
retrieving revision 1.6
diff -u -r1.6 tm-mipsv4.h
--- config/mips/tm-mipsv4.h	1 Jun 2003 14:45:28 -0000	1.6
+++ config/mips/tm-mipsv4.h	23 Nov 2003 20:17:46 -0000
@@ -23,7 +23,7 @@
 
 /* The signal handler trampoline is called _sigtramp.  */
 #undef IN_SIGTRAMP
-#define IN_SIGTRAMP(pc, name) ((name) && STREQ ("_sigtramp", name))
+#define IN_SIGTRAMP(pc, name) ((name) && DEPRECATED_STREQ ("_sigtramp", name))
 
 /* On entry to the signal handler trampoline, an ucontext is already
    pushed on the stack. We can get at the saved registers via the
Index: config/sparc/tm-sun4sol2.h
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/tm-sun4sol2.h,v
retrieving revision 1.12
diff -u -r1.12 tm-sun4sol2.h
--- config/sparc/tm-sun4sol2.h	22 Nov 2003 22:43:05 -0000	1.12
+++ config/sparc/tm-sun4sol2.h	23 Nov 2003 20:17:52 -0000
@@ -30,7 +30,7 @@
 /* There are two different signal handler trampolines in Solaris2.  */
 #define IN_SIGTRAMP(pc, name) \
   ((name) \
-   && (STREQ ("sigacthandler", name) || STREQ ("ucbsigvechandler", name)))
+   && (DEPRECATED_STREQ ("sigacthandler", name) || DEPRECATED_STREQ ("ucbsigvechandler", name)))
 
 /* The signal handler gets a pointer to an ucontext as third argument
    if it is called from sigacthandler.  This is the offset to the saved

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Sun, 23 Nov 2003 15:34:51 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> This patch deprecates remaining STREQ and STREQ uses.  These are the
> ones that weren't covered by my testing GDB on a stabs system.  It is
> worth noting that the bulk occure in language specific files - this
> suggests an area that needs improved testsuite coverage.

Sorry, I don't get the rationale for renaming STR* into
DEPRECATED_STR*.  Are we going to throw away the code that used
STREQN/STREQ?  If not, I don't see any good reasons to do this, as
renaming the macro doesn't get us any closer to the goal of replacing
them with a simple call to the appropriate str* function.

Could you please explain why the renaming is a good idea?

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> Date: Sun, 23 Nov 2003 15:34:51 -0500
>> From: Andrew Cagney <cagney@gnu.org>
>> 
>> This patch deprecates remaining STREQ and STREQ uses.  These are the
>> ones that weren't covered by my testing GDB on a stabs system.  It is
>> worth noting that the bulk occure in language specific files - this
>> suggests an area that needs improved testsuite coverage.
> 
> 
> Sorry, I don't get the rationale for renaming STR* into
> DEPRECATED_STR*.  Are we going to throw away the code that used
> STREQN/STREQ?  If not, I don't see any good reasons to do this, as
> renaming the macro doesn't get us any closer to the goal of replacing
> them with a simple call to the appropriate str* function.
> 
> Could you please explain why the renaming is a good idea?

Note that I'm renaming the _remaining_ STR*s and not all references.  I 
previously went through GDB's source code and replaced every occurance 
of STREQ* that is covered(1) by GDB's testsuite (or was in #ifdef 0 
code).  Since the before/after results were identical, I'm pretty sure 
those changes were ok.

Unfortunatly that still leaves GDB containing a notable number of STREQ 
references:
   49 ada-lang.c
    8 xcoffread.c
    7 coffread.c
    7 mdebugread.c
    6 dbxread.c
    6 rs6000-nat.c
    5 p-typeprint.c
    4 language.c
    4 mipsread.c
    3 dwarfread.c
    3 mcore-rom.c
    2 dwarf2read.c
    2 eval.c
    2 exec.c
    2 f-lang.c
    2 hpread.c
    2 source.c
    1 environ.c
    1 hppa-tdep.c
    1 objfiles.c
    1 p-valprint.c
    1 sparc-tdep.c
    1 stack.c
    1 target.c
While I could blindly transform those remaining references, such an 
operation would be untested and consequently runs the very real risk of 
introducing bugs (remember my test run didn't cover them).  Consequently 
they've been deprecated.

Per the weekend(2), they'll later be removed.

enjoy,
Andrew

(1) Using gcov.
(2) Check todays ARI (http://sources.redhat.com/gdb/current/ari) and 
you'll see a number of items have hit zero reference counts.

Re: [commit] Deprecate remaining STREQ uses

[Daniel Jacobowitz]

On Mon, Nov 24, 2003 at 11:41:36AM -0500, Andrew Cagney wrote:
> >Date: Sun, 23 Nov 2003 15:34:51 -0500
> >>From: Andrew Cagney <cagney@gnu.org>
> >>
> >>This patch deprecates remaining STREQ and STREQ uses.  These are the
> >>ones that weren't covered by my testing GDB on a stabs system.  It is
> >>worth noting that the bulk occure in language specific files - this
> >>suggests an area that needs improved testsuite coverage.
> >
> >
> >Sorry, I don't get the rationale for renaming STR* into
> >DEPRECATED_STR*.  Are we going to throw away the code that used
> >STREQN/STREQ?  If not, I don't see any good reasons to do this, as
> >renaming the macro doesn't get us any closer to the goal of replacing
> >them with a simple call to the appropriate str* function.
> >
> >Could you please explain why the renaming is a good idea?


> Note that I'm renaming the _remaining_ STR*s and not all references.  I 
> previously went through GDB's source code and replaced every occurance 
> of STREQ* that is covered(1) by GDB's testsuite (or was in #ifdef 0 
> code).  Since the before/after results were identical, I'm pretty sure 
> those changes were ok.
> 
> Unfortunatly that still leaves GDB containing a notable number of STREQ 
> references:
...
> While I could blindly transform those remaining references, such an 
> operation would be untested and consequently runs the very real risk of 
> introducing bugs (remember my test run didn't cover them).  Consequently 
> they've been deprecated.

Thank you for the details, Andrew, but you haven't answered Eli's
question.  The answer to his question lies in the leap between "blindly
transform" and "Consequently" - why not just _leave_ them? 
DEPRECATED_STREQ is not an improvement over STREQ except for making
things uglier.  We've even got the ARI to remind us; what you've
accomplished is shrinking the STREQ/STREQN column to zero at the
expense of raising the deprecated column even higher.  If that was all
you wanted you could have done it in the ARI scripts.

You've been pushing very hard to renaming things to deprecated_foo for
a while now.  I think I'm not the only other maintainer who doesn't
understand or approve.  It's a lot of work for you; it generates large
patches and source churn; it causes patch rejects and merge errors for
other developers; and the rest of us don't see or agree on the benefit.
Isn't that the sort of thing which should be discussed instead of
implemented?

Or am I out in a corner by myself here?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [commit] Deprecate remaining STREQ uses

[David Carlton]

On Mon, 24 Nov 2003 11:50:48 -0500, Daniel Jacobowitz <drow@mvista.com> said:

> You've been pushing very hard to renaming things to deprecated_foo
> for a while now.  I think I'm not the only other maintainer who
> doesn't understand or approve.  It's a lot of work for you; it
> generates large patches and source churn; it causes patch rejects
> and merge errors for other developers; and the rest of us don't see
> or agree on the benefit.  Isn't that the sort of thing which should
> be discussed instead of implemented?

Yes.  Having said that, I think that deprecation is often a good idea.
I like it when these conditions hold:

1) There is a new mechanism A replacing an old mechanism B.
   Everything that had been done with B can be done with A, and there
   is general agreement that A is better.

2) Adding 'deprecated_' will cause uses of B to diminish faster than
   not adding it would.

Part 2 comes in to play if you don't plan to make the switch
immediately (within the next month or so, say), and when you're afraid
that people who haven't been closely following the relevant discussion
will add uses of the old mechanism.

I'm not sure that STREQ meets the second criterion - frequent
contributors are good about not adding new uses of it.  So, from that
point of view, the merge difficulties (and even the newly introduced
long lines) argue against it.  I could go either way, though.

David Carlton
carlton@kealia.com

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Mon, 24 Nov 2003 10:02:27 -0800
> 
> I'm not sure that STREQ meets the second criterion - frequent
> contributors are good about not adding new uses of it.

We have ARI for that: even if new contributions escape Andrew's
and Elena's hawkish eyes and use STREQ, ARI will flag them.

Re: [commit] Deprecate remaining STREQ uses

[Kevin Buettner]

On Nov 24, 11:50am, Daniel Jacobowitz wrote:

> You've been pushing very hard to renaming things to deprecated_foo for
> a while now.  I think I'm not the only other maintainer who doesn't
> understand or approve.  It's a lot of work for you; it generates large
> patches and source churn; it causes patch rejects and merge errors for
> other developers; and the rest of us don't see or agree on the benefit.
> Isn't that the sort of thing which should be discussed instead of
> implemented?
> 
> Or am I out in a corner by myself here?

You are not off in a corner by yourself.

I think that renaming interfaces to contain the "deprecated_" prefix
has value in some instances, such as when the use of the interface is
filled with so much hair that it's risky to attempt to convert it
without a great deal of thought.

IMO, it should be possible to convert uses of STREQ/STREQN without
much risk.

I too would like to see discussion over whether a particular interface
ought to be deprecated or outright replaced instead of presenting the
renaming as a fait accompli.

Kevin

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> IMO, it should be possible to convert uses of STREQ/STREQN without
> much risk.

To speak from experience, I found 'n' fixed errors in even the existing 
conversions.  You'll note that some of the mamoth conversions that 
you've done in the past also had similar problems.

Anyway, Eli's pointed me at an automated tool for finishing the task.

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Kevin Buettner]

On Nov 24,  3:03pm, Andrew Cagney wrote:

> > IMO, it should be possible to convert uses of STREQ/STREQN without
> > much risk.
> 
> To speak from experience, I found 'n' fixed errors in even the existing 
> conversions.  You'll note that some of the mamoth conversions that 
> you've done in the past also had similar problems.

True.  I do recall having to fix problems in the code prior to starting
a conversion.

> Anyway, Eli's pointed me at an automated tool for finishing the task.

Automated tools are good.  (I figured you already had most of it
automated...)

Even if the process isn't entirely automated, it's still sometimes
better to do the conversion all at once.  By deprecating something,
you're forcing someone else (or even a later version of yourself) to
deal with the problem later on.  Chances are good that the person
making the changes understand the issues surrounding the change a lot
better than someone coming at it cold later on.  Also, doing it all at
once will (hopefully) ensure that the changes in question are done in
a uniform manner.

Kevin

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> Even if the process isn't entirely automated, it's still sometimes
> better to do the conversion all at once.  By deprecating something,
> you're forcing someone else (or even a later version of yourself) to
> deal with the problem later on.

If a contributor wants to add new code, or fix bugs in existing code, 
they should not be increasing the use of existing deprecated mechanisms 
(after all we should be able to reasonably expect contributors to not 
make matters worse).  The prime motivator here should our joint goal to 
make GDB the best debgger possible, and more immediatly our desire to 
fix bugs such as those identified by my rewritten structs.exp.  As for 
other code, let it bitrot and die.

To give two tangable examples:

http://sources.redhat.com/ml/gdb-patches/2003-08/msg00017.html
> See: http://sources.redhat.com/gdb/current/ari/
> The method get_frame_saved_regs() is obsolete. Changes should be decreasing, not increasing that function's usage count :-/ The new code will need to be written in a way that avoids this method. The best way of doing this is to convert it to convert that section of the code to the new unwind mechanism.

while I recommended using the new frame code, you'll note that I 
definitly didn't require it.  There were other ways of doing this that 
would have reduced the deprecated count that did not involve a frame 
conversion.

Similarly with the PPC and PPC64, you'll note that I've been fixing a 
depressing number of bugs in existing code, while at each step 
eliminating deprecated code.

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Thu, 27 Nov 2003 09:30:13 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> If a contributor wants to add new code, or fix bugs in existing code, 
> they should not be increasing the use of existing deprecated mechanisms 
> (after all we should be able to reasonably expect contributors to not 
> make matters worse).

But that's precisely why we have the patch review and approval
procedure, right?  Maintainers who approve patches are supposed to
prevent code that uses deprecated machinery from being added.

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

>> Date: Thu, 27 Nov 2003 09:30:13 -0500
>> From: Andrew Cagney <cagney@gnu.org>
>> 
>> If a contributor wants to add new code, or fix bugs in existing code, 
>> they should not be increasing the use of existing deprecated mechanisms 
>> (after all we should be able to reasonably expect contributors to not 
>> make matters worse).
> 
> 
> But that's precisely why we have the patch review and approval
> procedure, right?  Maintainers who approve patches are supposed to
> prevent code that uses deprecated machinery from being added.

Very true.  Explicit deprecation is a tool for making that part of the 
maintainer and contributor task far easier.  Instead of wasting time 
trying to track and find all the things being eliminated, the 
contributor and reviewer can simply keep an eye out for deprecated in 
their patches (and related calling).  This then lets both parties focus 
  their attention and efforts on the real reason for the review - ensure 
code quality and correctness.

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Mon, 01 Dec 2003 10:47:01 -0500
> From: Andrew Cagney <cagney@gnu.org>
> > 
> > But that's precisely why we have the patch review and approval
> > procedure, right?  Maintainers who approve patches are supposed to
> > prevent code that uses deprecated machinery from being added.
> 
> Very true.  Explicit deprecation is a tool for making that part of the 
> maintainer and contributor task far easier.  Instead of wasting time 
> trying to track and find all the things being eliminated, the 
> contributor and reviewer can simply keep an eye out for deprecated in 
> their patches

I'm not convinced that detecting STREQ is harder than detecting
DEPRECATED_STREQ.

Re: [commit] Deprecate remaining STREQ uses

[Daniel Jacobowitz]

On Mon, Dec 01, 2003 at 09:07:32PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 01 Dec 2003 10:47:01 -0500
> > From: Andrew Cagney <cagney@gnu.org>
> > > 
> > > But that's precisely why we have the patch review and approval
> > > procedure, right?  Maintainers who approve patches are supposed to
> > > prevent code that uses deprecated machinery from being added.
> > 
> > Very true.  Explicit deprecation is a tool for making that part of the 
> > maintainer and contributor task far easier.  Instead of wasting time 
> > trying to track and find all the things being eliminated, the 
> > contributor and reviewer can simply keep an eye out for deprecated in 
> > their patches
> 
> I'm not convinced that detecting STREQ is harder than detecting
> DEPRECATED_STREQ.

Neither am I... Andrew, how would you feel about a central (in the
source tree) list of deprecated objects instead?

Personally, I'd like for the ARI scripts to be in the source tree too.
$ make
init.c updated.
gcc -o gdb .....
$ make ari
sh $(srcdir)/gdb_ari.sh $(srcdir) ari-output.txt

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [commit] Deprecate remaining STREQ uses

[Joel Brobecker]

> $ make ari
> sh $(srcdir)/gdb_ari.sh $(srcdir) ari-output.txt

That'd be really nice!

-- 
Joel

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

> On Mon, Dec 01, 2003 at 09:07:32PM +0200, Eli Zaretskii wrote:
> 
>> > Date: Mon, 01 Dec 2003 10:47:01 -0500
>> > From: Andrew Cagney <cagney@gnu.org>
> 
>> > > 
>> > > But that's precisely why we have the patch review and approval
>> > > procedure, right?  Maintainers who approve patches are supposed to
>> > > prevent code that uses deprecated machinery from being added.
> 
>> > 
>> > Very true.  Explicit deprecation is a tool for making that part of the 
>> > maintainer and contributor task far easier.  Instead of wasting time 
>> > trying to track and find all the things being eliminated, the 
>> > contributor and reviewer can simply keep an eye out for deprecated in 
>> > their patches
> 
>> 
>> I'm not convinced that detecting STREQ is harder than detecting
>> DEPRECATED_STREQ.
> 
> 
> Neither am I... Andrew, how would you feel about a central (in the
> source tree) list of deprecated objects instead?

I see you didn't reply to the attached e-mail.

Andrew


[-- Attachment #2: mailbox-message://ac131313@movemail/fsf/gdb/patches#8370148 --]
[-- Type: message/rfc822, Size: 4019 bytes --]

From: Andrew Cagney <cagney@gnu.org>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [commit] Deprecate remaining STREQ uses
Date: Mon, 24 Nov 2003 17:08:54 -0500
Message-ID: <3FC28176.5020908@gnu.org>


> At least one now :)  There are a number of other solutions to this. 
> Have you considered making the ARI mail contributors for certain
> (low-false-positive) categories?  Like, for instance, this one.  The
> gcc-regression mailing list has several scripts to pull the ChangeLog
> entries since the last run and mail victims.  It's extremely effective.

I find the GCC script anything but effective.  I get spammed everytime I 
commit something to GCC - a very negative experience for an infrequent 
GCC committer.  I've now been conditioned into ignoring that mail :-(

Contrast that to -Werror (yes ok, it isn't a requirement) and 
gdb_mbuild.sh.  By encouraging their use we make it possible for people 
to address the problems _before_ they become an issue.  That way the 
contributor and maintainer don't even need to discuss them.  For 
something like the ARI to be mainlined, it would need to be integrated 
into the build process in a way that didn't leave the user confused (a 
standard build would have to be 100% warning free - something that at 
present is impossible to achieve).

enjoy,
Andrew

Re: [commit] Deprecate remaining STREQ uses

[Daniel Jacobowitz]

On Mon, Dec 01, 2003 at 04:25:51PM -0500, Andrew Cagney wrote:
> >On Mon, Dec 01, 2003 at 09:07:32PM +0200, Eli Zaretskii wrote:
> >
> >>> Date: Mon, 01 Dec 2003 10:47:01 -0500
> >>> From: Andrew Cagney <cagney@gnu.org>
> >
> >>> > 
> >>> > But that's precisely why we have the patch review and approval
> >>> > procedure, right?  Maintainers who approve patches are supposed to
> >>> > prevent code that uses deprecated machinery from being added.
> >
> >>> 
> >>> Very true.  Explicit deprecation is a tool for making that part of the 
> >>> maintainer and contributor task far easier.  Instead of wasting time 
> >>> trying to track and find all the things being eliminated, the 
> >>> contributor and reviewer can simply keep an eye out for deprecated in 
> >>> their patches
> >
> >>
> >>I'm not convinced that detecting STREQ is harder than detecting
> >>DEPRECATED_STREQ.
> >
> >
> >Neither am I... Andrew, how would you feel about a central (in the
> >source tree) list of deprecated objects instead?
> 
> I see you didn't reply to the attached e-mail.

You're right.  I was going to, so I'll do it below.  I fail to see how
it's related to the question above though.

> Date: Mon, 24 Nov 2003 17:08:54 -0500
> From: Andrew Cagney <cagney@gnu.org>
> Subject: Re: [commit] Deprecate remaining STREQ uses
> To: Daniel Jacobowitz <drow@mvista.com>
> Cc: gdb-patches@sources.redhat.com
> 
> 
> >At least one now :)  There are a number of other solutions to this. 
> >Have you considered making the ARI mail contributors for certain
> >(low-false-positive) categories?  Like, for instance, this one.  The
> >gcc-regression mailing list has several scripts to pull the ChangeLog
> >entries since the last run and mail victims.  It's extremely effective.
> 
> I find the GCC script anything but effective.  I get spammed everytime I 
> commit something to GCC - a very negative experience for an infrequent 
> GCC committer.  I've now been conditioned into ignoring that mail :-(

This is not the normal state of affairs.  Normally bootstraps do work,
and I only get mail when someone has newly broken the tree - and of the
four times that's happened one of them was me, so I'd call it pretty
good results.

ARI runs a _lot_ faster than a GCC build/regression session.  If you
set the script to mail only on increases in problems, rather than on
existing problems, you should be able to get a response pretty much at
per-patch granularity.  This is different from the way GCC uses their
system, because GCC has an extremely different attitude towards the
testsuite - failures are absolutely unacceptable.

> Contrast that to -Werror (yes ok, it isn't a requirement) and 
> gdb_mbuild.sh.  By encouraging their use we make it possible for people 
> to address the problems _before_ they become an issue.  That way the 
> contributor and maintainer don't even need to discuss them.  For 
> something like the ARI to be mainlined, it would need to be integrated 
> into the build process in a way that didn't leave the user confused (a 
> standard build would have to be 100% warning free - something that at 
> present is impossible to achieve).

Check in the baseline status to the repository if you want to do that. 
Generate it during builds.  Require people who check in patches which
add ARI problems to also check in a patch bumping the failure totals,
and it'll be obvious what's going on and where problems come from.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

>> >>> Very true.  Explicit deprecation is a tool for making that part of the 
>> >>> maintainer and contributor task far easier.  Instead of wasting time 
>> >>> trying to track and find all the things being eliminated, the 
>> >>> contributor and reviewer can simply keep an eye out for deprecated in 
>> >>> their patches
> 
>> >
> 
>> >>
>> >>I'm not convinced that detecting STREQ is harder than detecting
>> >>DEPRECATED_STREQ.
> 
>> >
>> >
>> >Neither am I... Andrew, how would you feel about a central (in the
>> >source tree) list of deprecated objects instead?
> 
>> 
>> I see you didn't reply to the attached e-mail.
> 
> 
> You're right.  I was going to, so I'll do it below.  I fail to see how
> it's related to the question above though.

You proposed a change.  I sketched out a rough set of criteria against 
which that alternative should be measured.

>> Date: Mon, 24 Nov 2003 17:08:54 -0500
>> From: Andrew Cagney <cagney@gnu.org>
>> Subject: Re: [commit] Deprecate remaining STREQ uses
>> To: Daniel Jacobowitz <drow@mvista.com>
>> Cc: gdb-patches@sources.redhat.com
>> 
>> 
> 
>> >At least one now :)  There are a number of other solutions to this. 
>> >Have you considered making the ARI mail contributors for certain
>> >(low-false-positive) categories?  Like, for instance, this one.  The
>> >gcc-regression mailing list has several scripts to pull the ChangeLog
>> >entries since the last run and mail victims.  It's extremely effective.
> 
>> 
>> I find the GCC script anything but effective.  I get spammed everytime I 
>> commit something to GCC - a very negative experience for an infrequent 
>> GCC committer.  I've now been conditioned into ignoring that mail :-(
> 
> 
> This is not the normal state of affairs.  Normally bootstraps do work,
> and I only get mail when someone has newly broken the tree - and of the
> four times that's happened one of them was me, so I'd call it pretty
> good results.

For GCC, perhaphs.  In general, such systems do the testing up front 
ensuring that only fully qualified changes get committed.  GCC is an 
atypical model here.

> ARI runs a _lot_ faster than a GCC build/regression session.  If you
> set the script to mail only on increases in problems, rather than on
> existing problems, you should be able to get a response pretty much at
> per-patch granularity.  This is different from the way GCC uses their
> system, because GCC has an extremely different attitude towards the
> testsuite - failures are absolutely unacceptable.

After the commit is too late.  As I note below, the contributor must be 
both aware of and be able to address the problem _before_ they submit 
their patch.  That way they, and the maintainer, avoid bickering of 
things that really should not even need a discussion.

>> Contrast that to -Werror (yes ok, it isn't a requirement) and 
>> gdb_mbuild.sh.  By encouraging their use we make it possible for people 
>> to address the problems _before_ they become an issue.  That way the 
>> contributor and maintainer don't even need to discuss them.  For 
>> something like the ARI to be mainlined, it would need to be integrated 
>> into the build process in a way that didn't leave the user confused (a 
>> standard build would have to be 100% warning free - something that at 
>> present is impossible to achieve).
> 
> 
> Check in the baseline status to the repository if you want to do that. 
> Generate it during builds.  Require people who check in patches which
> add ARI problems to also check in a patch bumping the failure totals,
> and it'll be obvious what's going on and where problems come from.

Any change needs to be a natural part of the development cycle:

	modify
	build
	test
	submit
	review
	commit

The existing deprecate works because looking for deprecated is a 
relatively natural part of the patch review phase (and the issue is 
trivially addressed by contributors before they post their submition - 
if you look over the mailing lists you'll see a very high success rate 
and few problems with new contributors).

Given that the ARI takes a measurable amount of time to run, it can't be 
addeded to the build process.  However, as part of the testsuite might 
be more interesting:

FAIL: number of occurances increases
KPASS: number of occurances decreased
PASS: something is zero
KFAIL: number of occurances remained static

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> Any change needs to be a natural part of the development cycle:
> 
>     modify
>     build
>     test
>     submit
>     review
>     commit
> 
> The existing deprecate works because looking for deprecated is a relatively natural part of the patch review phase (and the issue is trivially addressed by contributors before they post their submition - if you look over the mailing lists you'll see a very high success rate and few problems with new contributors).
> 
> Given that the ARI takes a measurable amount of time to run, it can't be addeded to the build process.  However, as part of the testsuite might be more interesting:
> 
> FAIL: number of occurances increases
> KPASS: number of occurances decreased
> PASS: something is zero
> KFAIL: number of occurances remained static

Two PSs:

Even cheaper / simpler is to have financially driven corporations trying 
to squeeze the last drop out ofcontracts involving the maintenance of 
legacy code just create an internal "deprecated.h" file that contains 
hacks like:
	#define deprecated_npc_regnum npc_regnum
and then #include that.  While personally I'd just track the deprecated 
names, this is certainly a cheep option.

My moving deprecated tests to the testsuite or build process the quality 
of code expected from GDB contributors is significantly reduced - the 
acceptance criteria is that they don't increase the deprecated count - 
_not_ that deprecated code is cleaned up as one goes.

(But note this is speaking generally and not in relation to STREQ)

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> Very true.  Explicit deprecation is a tool for making that part of the 
>> maintainer and contributor task far easier.  Instead of wasting time 
>> trying to track and find all the things being eliminated, the 
>> contributor and reviewer can simply keep an eye out for deprecated in 
>> their patches
> 
> 
> I'm not convinced that detecting STREQ is harder than detecting
> DEPRECATED_STREQ.

I was talking generally.  There are currently 99 deprecated methods (and 
a further 78 that are listed as potential candidates).  I don't think 
anyone could reasonably be expected to keep track of all of that, least 
of all a non-core contributor.

Anyway, I think the STREQ specific issue has been beaten to death.  I've 
now learnt a robust mechanical way of eliminating the macro and will 
endevor to shortly eliminate it.

enjoy,
Andrew

Re: [commit] Deprecate remaining STREQ uses

[Kevin Buettner]

On Nov 27,  9:30am, Andrew Cagney wrote:

> > Even if the process isn't entirely automated, it's still sometimes
> > better to do the conversion all at once.  By deprecating something,
> > you're forcing someone else (or even a later version of yourself) to
> > deal with the problem later on.
> 
> If a contributor wants to add new code, or fix bugs in existing code, 
> they should not be increasing the use of existing deprecated mechanisms 
> (after all we should be able to reasonably expect contributors to not 
> make matters worse).  The prime motivator here should our joint goal to 
> make GDB the best debgger possible, and more immediatly our desire to 
> fix bugs such as those identified by my rewritten structs.exp.  As for 
> other code, let it bitrot and die.

I agree with much of what you say, but I really can't agree with the
last part.  There is a quite a lot of code which simply cannot be
allowed to "bitrot and die".

I have already stated that I think the renaming of deprecated
interfaces is okay in some instances.  I am concerned, however, that
this approach is being used in instances where it doesn't really
need to be.

Kevin

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Wed, 3 Dec 2003 21:44:04 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> 
> I have already stated that I think the renaming of deprecated
> interfaces is okay in some instances.  I am concerned, however, that
> this approach is being used in instances where it doesn't really
> need to be.

Seconded.

Can we conclude this thread by agreeing that renaming of deprecated
interfaces should be discussed first in cases such as STREQ?  I think 
everybody agreed on that at some point.

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

>> Date: Wed, 3 Dec 2003 21:44:04 -0700
>> If a contributor wants to add new code, or fix bugs in existing code, 
>>> they should not be increasing the use of existing deprecated mechanisms 
>>> (after all we should be able to reasonably expect contributors to not 
>>> make matters worse).  The prime motivator here should our joint goal to 
>>> make GDB the best debgger possible, and more immediatly our desire to 
>>> fix bugs such as those identified by my rewritten structs.exp.  As for 
>>> other code, let it bitrot and die.
>> 
>> 
>> I agree with much of what you say, but I really can't agree with the
>> last part.  There is a quite a lot of code which simply cannot be
>> allowed to "bitrot and die".

Kevin's comment here is way over my head.

Firstly we're actively maintaining and improve our code base, as if we 
fail to do this, our code will bitrot and die.  This isn't because of 
deprecation, rather its because GDB is part of a rapidly chaning world - 
GCC changes, the OS changes - and each change creates new and wonderful 
requirements while at the same time unearthing old bugs.

An unfortunate consequence of this is that sections of the code base 
will fall by the wayside (if they were sufficiently important one of us 
would have step up and sort out the mess - as mark has done for the 
SPARC).  I say let it.  We've better things to spend our limited 
resources on such as (as eli observed) adding new features and 
functionality to GDB.

So, to put it simply, what code?

>> From: Kevin Buettner <kevinb@redhat.com>
>> 
>> I have already stated that I think the renaming of deprecated
>> interfaces is okay in some instances.  I am concerned, however, that
>> this approach is being used in instances where it doesn't really
>> need to be.
> 
> 
> Seconded.
> 
> Can we conclude this thread by agreeing that renaming of deprecated
> interfaces should be discussed first in cases such as STREQ?  I think 
> everybody agreed on that at some point.

To speak generally, what happens is:

- an interface is identified as a deprecate candidate
See "deprecate" in the ari for a candidate list - most are macros but 
others are cases where the code could do with a refactoring.

- the deprecate candidate gets reviewed, replaced or rewritten
It is at this point that the issue is raised publically, problems in the 
old iterface identified and discussed, and the issue resolved.  Any old 
interfaces get identified as obsolete, ready for the final phase ...

- the now obsolete interface and mechanism get explicitly deprecated
(or removed, depending on how risky it is)

(Of course there are variations on a theme - sometimes the old interface 
is deprecated first as that makes the introduction of the new interface 
easier.)

So there is already a point at which this deprecate can be discussed.

However, more puzzling is Kevin's generalization that "this approach is 
being used in instances where it really doesn't need to be".  It 
strongly implies that STREQ, rather than being the exception, is the 
norm.  If if that is the case then more details would be helpful.

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Thu, 04 Dec 2003 12:32:58 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> So there is already a point at which this deprecate can be discussed.

Right, but in the specific case that started this thread, it looks
like we somehow missed that point.  I wanted to make sure that we all
agreed we should try to avoid such misses.

Re: [commit] Deprecate remaining STREQ uses

[Kevin Buettner]

On Dec 4, 12:32pm, Andrew Cagney wrote:

> >> If a contributor wants to add new code, or fix bugs in existing code, 
> >>> they should not be increasing the use of existing deprecated mechanisms 
> >>> (after all we should be able to reasonably expect contributors to not 
> >>> make matters worse).  The prime motivator here should our joint goal to 
> >>> make GDB the best debgger possible, and more immediatly our desire to 
> >>> fix bugs such as those identified by my rewritten structs.exp.  As for 
> >>> other code, let it bitrot and die.
> >> 
> >> I agree with much of what you say, but I really can't agree with the
> >> last part.  There is a quite a lot of code which simply cannot be
> >> allowed to "bitrot and die".
> 
> Kevin's comment here is way over my head.
> 
> Firstly we're actively maintaining and improve our code base, as if we 
> fail to do this, our code will bitrot and die.  This isn't because of 
> deprecation, rather its because GDB is part of a rapidly chaning world - 
> GCC changes, the OS changes - and each change creates new and wonderful 
> requirements while at the same time unearthing old bugs.
> 
> An unfortunate consequence of this is that sections of the code base 
> will fall by the wayside (if they were sufficiently important one of us 
> would have step up and sort out the mess - as mark has done for the 
> SPARC).  I say let it.  We've better things to spend our limited 
> resources on such as (as eli observed) adding new features and 
> functionality to GDB.
> 
> So, to put it simply, what code?

Symbol readers (some of them anyway), MIPS architecture, PPC
architecture, to name three.

> >> From: Kevin Buettner <kevinb@redhat.com>
> >> 
> >> I have already stated that I think the renaming of deprecated
> >> interfaces is okay in some instances.  I am concerned, however, that
> >> this approach is being used in instances where it doesn't really
> >> need to be.
[...]
> However, more puzzling is Kevin's generalization that "this approach is 
> being used in instances where it really doesn't need to be".  It 
> strongly implies that STREQ, rather than being the exception, is the 
> norm.  If if that is the case then more details would be helpful.

One (admittedly historic) example is the introduction of the complaint()
interface.  As I recall, the old (now removed) interface was called
complain() and a new interface named complaint() was introduced.  There
were good reasons for wanting a new interface; as I recall, the new
interface allowed compile time checking of the call's arguments with
respect to a format string whereas the old interface did not.  So,
I have no problem with the introduction of the new interface.  The
bit that I have a problem with is that calls to the old interface
were left in place after the new interface was introduced.  As I recall,
I made a change to dwarf2read.c which used the old interface.  I
was immediately admonished to use the new interface.  IMO, it's
really ugly to have some code in a source file use an old interface
while other code in the same source file uses the new interface, so I
set out to correct this problem - which I did.  But, also IMO, the
person introducing the new interface ought to have done the work of
eliminating the old interface.

I suspect that what this boils down to is a difference in maintenance
philosophy: I would prefer to see old (deprecated) interfaces eliminated
as soon as possible even if it does involve touching possible candidates
for deletion, whereas you don't seem to mind having old interfaces
retained for longer periods of time.

Kevin

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> On Dec 4, 12:32pm, Andrew Cagney wrote:
> 
> 
>> >> If a contributor wants to add new code, or fix bugs in existing code, 
> 
>> >>> they should not be increasing the use of existing deprecated mechanisms 
>> >>> (after all we should be able to reasonably expect contributors to not 
>> >>> make matters worse).  The prime motivator here should our joint goal to 
>> >>> make GDB the best debgger possible, and more immediatly our desire to 
>> >>> fix bugs such as those identified by my rewritten structs.exp.  As for 
>> >>> other code, let it bitrot and die.
> 
>> >> 
>> >> I agree with much of what you say, but I really can't agree with the
>> >> last part.  There is a quite a lot of code which simply cannot be
>> >> allowed to "bitrot and die".
> 
>> 
>> Kevin's comment here is way over my head.
>> 
>> Firstly we're actively maintaining and improve our code base, as if we 
>> fail to do this, our code will bitrot and die.  This isn't because of 
>> deprecation, rather its because GDB is part of a rapidly chaning world - 
>> GCC changes, the OS changes - and each change creates new and wonderful 
>> requirements while at the same time unearthing old bugs.
>> 
>> An unfortunate consequence of this is that sections of the code base 
>> will fall by the wayside (if they were sufficiently important one of us 
>> would have step up and sort out the mess - as mark has done for the 
>> SPARC).  I say let it.  We've better things to spend our limited 
>> resources on such as (as eli observed) adding new features and 
>> functionality to GDB.
>> 
>> So, to put it simply, what code?
> 
> 
> Symbol readers (some of them anyway), MIPS architecture, PPC
> architecture, to name three.

Sorry, I'm again lost.

Over the last while I committed more fixes and cleanups to MIPS and PPC 
- their testsuite failures went down.  As for symbol readers, we've not 
got that many left.  Both Michael and Joel are casting an evil eye at HP 
though.

>> >> From: Kevin Buettner <kevinb@redhat.com>
>> >> 
>> >> I have already stated that I think the renaming of deprecated
>> >> interfaces is okay in some instances.  I am concerned, however, that
>> >> this approach is being used in instances where it doesn't really
>> >> need to be.
> 
> [...]
> 
>> However, more puzzling is Kevin's generalization that "this approach is 
>> being used in instances where it really doesn't need to be".  It 
>> strongly implies that STREQ, rather than being the exception, is the 
>> norm.  If if that is the case then more details would be helpful.
> 
> 
> One (admittedly historic) example is the introduction of the complaint()
> interface.  As I recall, the old (now removed) interface was called
> complain() and a new interface named complaint() was introduced.  There
> were good reasons for wanting a new interface; as I recall, the new
> interface allowed compile time checking of the call's arguments with
> respect to a format string whereas the old interface did not.  So,
> I have no problem with the introduction of the new interface.  The
> bit that I have a problem with is that calls to the old interface
> were left in place after the new interface was introduced.  As I recall,
> I made a change to dwarf2read.c which used the old interface.  I
> was immediately admonished to use the new interface.  IMO, it's
> really ugly to have some code in a source file use an old interface
> while other code in the same source file uses the new interface, so I
> set out to correct this problem - which I did.  But, also IMO, the
> person introducing the new interface ought to have done the work of
> eliminating the old interface.

http://sources.redhat.com/ml/gdb-patches/2002-10/msg00370.html

> I suspect that what this boils down to is a difference in maintenance
> philosophy: I would prefer to see old (deprecated) interfaces eliminated
> as soon as possible even if it does involve touching possible candidates
> for deletion, whereas you don't seem to mind having old interfaces
> retained for longer periods of time.

To make this more concrete, perhaphs you could outline how this would 
have worked with the old vs new frame code.

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> I too would like to see discussion over whether a particular interface
> ought to be deprecated or outright replaced instead of presenting the
> renaming as a fait accompli.

Please explain.

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Kevin Buettner]

On Nov 24,  3:32pm, Andrew Cagney wrote:

> > I too would like to see discussion over whether a particular interface
> > ought to be deprecated or outright replaced instead of presenting the
> > renaming as a fait accompli.
> 
> Please explain.

This STREQ issue is a good example.  You chose to post an already
committed patch which did the renaming instead of first discussing the
approaches by which STREQ could be eliminated.  IMO, it would have been
better to discuss the matter first and arrive at a consensus on how it
should be eliminated.  (Or even if it should be eliminated.)

Kevin

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> On Nov 24,  3:32pm, Andrew Cagney wrote:
> 
> 
>> > I too would like to see discussion over whether a particular interface
>> > ought to be deprecated or outright replaced instead of presenting the
>> > renaming as a fait accompli.
> 
>> 
>> Please explain.
> 
> 
> This STREQ issue is a good example.  You chose to post an already
> committed patch which did the renaming instead of first discussing the
> approaches by which STREQ could be eliminated.  IMO, it would have been
> better to discuss the matter first and arrive at a consensus on how it
> should be eliminated.  (Or even if it should be eliminated.)

Are you talking generally or just in terms of STREQ?  STREQ is somewhat 
a-typical in that my earlier "obish" s/STREQ/strcmp/ changes met with 
zero comment (objection or thanks) - consequently I don't think it was 
totally unreasonable of me to assume that deprecating the remainder 
would be safe.  It wasn't.  "oops".

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Mon, 24 Nov 2003 20:33:43 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> my earlier "obish" s/STREQ/strcmp/ changes met with zero comment
> (objection or thanks)

That's because such a replacement is indeed "obish", given that we
decided long ago to get rid of STREQ.

Re: [commit] Deprecate remaining STREQ uses

[Kevin Buettner]

On Nov 24,  8:33pm, Andrew Cagney wrote:

> >> > I too would like to see discussion over whether a particular interface
> >> > ought to be deprecated or outright replaced instead of presenting the
> >> > renaming as a fait accompli.
> > 
> >> Please explain.
> > 
> > This STREQ issue is a good example.  You chose to post an already
> > committed patch which did the renaming instead of first discussing the
> > approaches by which STREQ could be eliminated.  IMO, it would have been
> > better to discuss the matter first and arrive at a consensus on how it
> > should be eliminated.  (Or even if it should be eliminated.)
> 
> Are you talking generally or just in terms of STREQ?

Generally.

As I stated earlier, I think we should try to reach some sort of
consensus regarding which interfaces to deprecate.

Kevin

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Mon, 24 Nov 2003 11:50:48 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> You've been pushing very hard to renaming things to deprecated_foo for
> a while now.  I think I'm not the only other maintainer who doesn't
> understand or approve.  It's a lot of work for you; it generates large
> patches and source churn; it causes patch rejects and merge errors for
> other developers; and the rest of us don't see or agree on the benefit.

FWIW, I generally approve of the practice to rename deprecated
features _assuming_that_they_are_on_their_way_to_oblivion_.  That
way, we give people/ports some time to prepare themselves for the
removal, or to mount a campaign against such removal.

But renaming code that isn't going to go away, but to be simply
rewritten in a trivial way, is indeed a terrible waste of our
resources, IMHO.

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> Date: Mon, 24 Nov 2003 11:50:48 -0500
>> From: Daniel Jacobowitz <drow@mvista.com>
>> 
>> You've been pushing very hard to renaming things to deprecated_foo for
>> a while now.  I think I'm not the only other maintainer who doesn't
>> understand or approve.  It's a lot of work for you; it generates large
>> patches and source churn; it causes patch rejects and merge errors for
>> other developers; and the rest of us don't see or agree on the benefit.
> 
> 
> FWIW, I generally approve of the practice to rename deprecated
> features _assuming_that_they_are_on_their_way_to_oblivion_.  That
> way, we give people/ports some time to prepare themselves for the
> removal, or to mount a campaign against such removal.
> 
> But renaming code that isn't going to go away, but to be simply
> rewritten in a trivial way, is indeed a terrible waste of our
> resources, IMHO.

BTW, coff (not xcoff) support which is where (ignoring ada, hi joel) 
most of the remaining references occure _is_ heading for oblivion.  I 
just sent out patches to wack m68k and mips svr3 support.  That leaves 
just i386 and alpha.

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Joel Brobecker]

> BTW, coff (not xcoff) support which is where (ignoring ada, hi joel) 

I will take care of removing all STREQ* usage from our ada-specific
files. This update will then be contributed when we are finally ready to
merge our sources into your tree.

Note, this raise another question: I consider that the Ada experience
that we started a year ago (or maybe even longer) has failed. Since
then, the ada-specific files tend to suffer from bitrot, and I presume
that they also sometimes cause a small maintenance overhead when large
changes such as this one are done. Shouldn't it make better sense to
simply remove this file for now? It can be added back when we deliver.

-- 
Joel

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

>> BTW, coff (not xcoff) support which is where (ignoring ada, hi joel) 
> 
> 
> I will take care of removing all STREQ* usage from our ada-specific
> files. This update will then be contributed when we are finally ready to
> merge our sources into your tree.

Thanks.  You'll see that I tweaked the ARI so that it doesn't include ada.

> Note, this raise another question: I consider that the Ada experience
> that we started a year ago (or maybe even longer) has failed. Since
> then, the ada-specific files tend to suffer from bitrot, and I presume
> that they also sometimes cause a small maintenance overhead when large
> changes such as this one are done. Shouldn't it make better sense to
> simply remove this file for now? It can be added back when we deliver.

I think having the code there is still helpful.  It gave other 
developers some context, for instance when recently studying PaulH's 
expression changes.  It also lets us see the problems that are heading 
our way (that thread stuff :-).

enjoy,
Andrew

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Mon, 24 Nov 2003 14:58:22 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> BTW, coff (not xcoff) support which is where (ignoring ada, hi joel) 
> most of the remaining references occure _is_ heading for oblivion.  I 
> just sent out patches to wack m68k and mips svr3 support.  That leaves 
> just i386 and alpha.

Well, i386 is not going away any time soon, I suppose.  DJGPP uses
COFF ;-).

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> Thank you for the details, Andrew, but you haven't answered Eli's
> question.  The answer to his question lies in the leap between "blindly
> transform" and "Consequently" - why not just _leave_ them? 
> DEPRECATED_STREQ is not an improvement over STREQ except for making
> things uglier.  We've even got the ARI to remind us; what you've
> accomplished is shrinking the STREQ/STREQN column to zero at the
> expense of raising the deprecated column even higher.  If that was all
> you wanted you could have done it in the ARI scripts.

David summarized the rationale nicely.  Some additional data points are 
useful though:

- no one looks at the ARI
Looking at the last month of weekly web page summaries they range from:
    2734	/gdb/
    ....
     170	/gdb/current/
     ...
      32	/ml/bug-gdb/2000-12/msg00014.html
but contain not one mention of the ARI (even though I refer to it 
regularly).

- no one should need to look at the ARI
GDB's code base should internally document the status of each interface. 
    That way, when someone goes to hack on something its status is very 
clear.  Contributors can look at a slab of code and know immediatly that 
there is a problem.  Maintainers can review a patch and know where a 
deprecated interface is being used.

- it's more transparent
It's clearly far harder for me (and you) to let slip through patches 
that contain deprecated references.

> You've been pushing very hard to renaming things to deprecated_foo for
> a while now.  I think I'm not the only other maintainer who doesn't
> understand or approve.  It's a lot of work for you; it generates large
> patches and source churn; it causes patch rejects and merge errors for
> other developers; and the rest of us don't see or agree on the benefit.
> Isn't that the sort of thing which should be discussed instead of
> implemented?

This isn't exactly new:

ChangeLog-1998: (struct frame_saved_regs): Deprecate.
ChangeLog-1998: (EXTRA_FRAME_INFO): Deprecate.
ChangeLog-1998: (get_frame_saved_regs): Deprecate. Copy the saved regs 
into the
ChangeLog-1998: * symfile.c (allocate_symtab): Deprecate use of
ChangeLog-1999:         memory-write-packet-size''.  Deprecate ``set 
remotepacketsize''.
ChangeLog-1999:         print_transfer_performance. Deprecate.
ChangeLog-1999: deprecated gdb_file_init_astream().
ChangeLog-1999: * serial.h (DEPRECATED_SERIAL_FD): Define.
ChangeLog-1999: * serial.c (deprecated_serial_fd): New function.
ChangeLog-1999: * ui-out.c (struct ui_out): Remove deprecated fields.

With STREQ discussed:

ChangeLog-2000: * TODO: Mention ``extern'' and ``STREQ'' cleanups.
ChangeLog-2000: * defs.h (STREQ, STRCMP, STREQN): Document that these 
macros are
http://sources.redhat.com/ml/gdb-patches/2000-q1/msg00667.html
('m sure there's a second thread but can't find it).

only shame is that I didn't realse that GCOV could be used back then to 
test the change.

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Daniel Jacobowitz]

On Mon, Nov 24, 2003 at 02:36:47PM -0500, Andrew Cagney wrote:
> 
> >Thank you for the details, Andrew, but you haven't answered Eli's
> >question.  The answer to his question lies in the leap between "blindly
> >transform" and "Consequently" - why not just _leave_ them? 
> >DEPRECATED_STREQ is not an improvement over STREQ except for making
> >things uglier.  We've even got the ARI to remind us; what you've
> >accomplished is shrinking the STREQ/STREQN column to zero at the
> >expense of raising the deprecated column even higher.  If that was all
> >you wanted you could have done it in the ARI scripts.
> 
> David summarized the rationale nicely.  Some additional data points are 
> useful though:
> 
> - no one looks at the ARI
> Looking at the last month of weekly web page summaries they range from:
>    2734	/gdb/
>    ....
>     170	/gdb/current/
>     ...
>      32	/ml/bug-gdb/2000-12/msg00014.html
> but contain not one mention of the ARI (even though I refer to it 
> regularly).

At least one now :)  There are a number of other solutions to this. 
Have you considered making the ARI mail contributors for certain
(low-false-positive) categories?  Like, for instance, this one.  The
gcc-regression mailing list has several scripts to pull the ChangeLog
entries since the last run and mail victims.  It's extremely effective.

> - no one should need to look at the ARI
> GDB's code base should internally document the status of each interface. 
>    That way, when someone goes to hack on something its status is very 
> clear.  Contributors can look at a slab of code and know immediatly that 
> there is a problem.  Maintainers can review a patch and know where a 
> deprecated interface is being used.
> 
> - it's more transparent
> It's clearly far harder for me (and you) to let slip through patches 
> that contain deprecated references.

This is where we disagree, I think.

Not that I'm arguing with either of the above.  But I believe that the
problems (below) need to be considered also.  With work to make the ARI
more used (as opposed to useful) I think you could save everyone a lot
of time.

> >You've been pushing very hard to renaming things to deprecated_foo for
> >a while now.  I think I'm not the only other maintainer who doesn't
> >understand or approve.  It's a lot of work for you; it generates large
> >patches and source churn; it causes patch rejects and merge errors for
> >other developers; and the rest of us don't see or agree on the benefit.
> >Isn't that the sort of thing which should be discussed instead of
> >implemented?
> 
> This isn't exactly new:
> 
> ChangeLog-1998: (struct frame_saved_regs): Deprecate.
> ChangeLog-1998: (EXTRA_FRAME_INFO): Deprecate.
> ChangeLog-1998: (get_frame_saved_regs): Deprecate. Copy the saved regs 
> into the
> ChangeLog-1998: * symfile.c (allocate_symtab): Deprecate use of
> ChangeLog-1999:         memory-write-packet-size''.  Deprecate ``set 
> remotepacketsize''.
> ChangeLog-1999:         print_transfer_performance. Deprecate.
> ChangeLog-1999: deprecated gdb_file_init_astream().
> ChangeLog-1999: * serial.h (DEPRECATED_SERIAL_FD): Define.
> ChangeLog-1999: * serial.c (deprecated_serial_fd): New function.
> ChangeLog-1999: * ui-out.c (struct ui_out): Remove deprecated fields.
> 
> With STREQ discussed:
> 
> ChangeLog-2000: * TODO: Mention ``extern'' and ``STREQ'' cleanups.
> ChangeLog-2000: * defs.h (STREQ, STRCMP, STREQN): Document that these 
> macros are
> http://sources.redhat.com/ml/gdb-patches/2000-q1/msg00667.html
> ('m sure there's a second thread but can't find it).

Sure it isn't new.  Other people grumbling at you when you deprecate
things doesn't appear to be new either.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> At least one now :)  There are a number of other solutions to this. 
> Have you considered making the ARI mail contributors for certain
> (low-false-positive) categories?  Like, for instance, this one.  The
> gcc-regression mailing list has several scripts to pull the ChangeLog
> entries since the last run and mail victims.  It's extremely effective.

I find the GCC script anything but effective.  I get spammed everytime I 
commit something to GCC - a very negative experience for an infrequent 
GCC committer.  I've now been conditioned into ignoring that mail :-(

Contrast that to -Werror (yes ok, it isn't a requirement) and 
gdb_mbuild.sh.  By encouraging their use we make it possible for people 
to address the problems _before_ they become an issue.  That way the 
contributor and maintainer don't even need to discuss them.  For 
something like the ARI to be mainlined, it would need to be integrated 
into the build process in a way that didn't leave the user confused (a 
standard build would have to be 100% warning free - something that at 
present is impossible to achieve).

enjoy,
Andrew

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Mon, 24 Nov 2003 11:41:36 -0500
> From: Andrew Cagney <cagney@gnu.org>
> > 
> > Sorry, I don't get the rationale for renaming STR* into
> > DEPRECATED_STR*.  Are we going to throw away the code that used
> > STREQN/STREQ?  If not, I don't see any good reasons to do this, as
> > renaming the macro doesn't get us any closer to the goal of replacing
> > them with a simple call to the appropriate str* function.
> > 
> > Could you please explain why the renaming is a good idea?
> 
> Note that I'm renaming the _remaining_ STR*s and not all references.

I must be dense today, because I still don't get it.

What is the importance of ``remaining'' in this case?  I understand
that you replaced some of the uses of STR* macros, those that you
could test on the system(s) you have available to you, with the direct
call to the str* functions.  I can also understand (although I
basically disagree, see below) why you don't want to replace those
uses which you cannot test.  But why does it make sense to rename
them?  Why not just leave them alone?

What am I missing?

> Since the before/after results were identical, I'm pretty sure 
> those changes were ok.

Do we really need to test a purely mechanistic replacement of STREQ
with strcmp() == 0?

> While I could blindly transform those remaining references, such an 
> operation would be untested and consequently runs the very real risk of 
> introducing bugs (remember my test run didn't cover them).  Consequently 
> they've been deprecated.

I don't think simply replacing the macros with their expansion could
introduce bugs.  If you don't trust your eyes and hands, perhaps
Emacs's c-macro-expand command (or some other similar automated tool)
could help.

But even if I accept your reasoning about possible bugs, I still don't
get why renaming the macros is a good idea.  It sounds simply a
gratuitous change.

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

>> Date: Mon, 24 Nov 2003 11:41:36 -0500
>> From: Andrew Cagney <cagney@gnu.org>
> 
>> > 
>> > Sorry, I don't get the rationale for renaming STR* into
>> > DEPRECATED_STR*.  Are we going to throw away the code that used
>> > STREQN/STREQ?  If not, I don't see any good reasons to do this, as
>> > renaming the macro doesn't get us any closer to the goal of replacing
>> > them with a simple call to the appropriate str* function.
>> > 
>> > Could you please explain why the renaming is a good idea?
> 
>> 
>> Note that I'm renaming the _remaining_ STR*s and not all references.
> 
> 
> I must be dense today, because I still don't get it.
> 
> What is the importance of ``remaining'' in this case?  I understand
> that you replaced some of the uses of STR* macros, those that you
> could test on the system(s) you have available to you, with the direct
> call to the str* functions.  I can also understand (although I
> basically disagree, see below) why you don't want to replace those
> uses which you cannot test.  But why does it make sense to rename
> them?  Why not just leave them alone?
> 
> What am I missing?

To ensure that future patches don't continue to use these macros.

> I don't think simply replacing the macros with their expansion could
> introduce bugs.  If you don't trust your eyes and hands, perhaps
> Emacs's c-macro-expand command (or some other similar automated tool)
> could help.

(it isn't a question of trusing eyes or hands but accepting that humans 
are falible).   Anyway, so EMACS has an automated tool I'll go through 
with that.  Expect questions ;-)  Do I need to run ETAGS first?

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Mon, 24 Nov 2003 14:45:01 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> Expect questions ;-)

Be my guest ;-)

> Do I need to run ETAGS first?

Etags won't help, as all it knows is where STREQ is _defined_, not
where it's _used_.  What you want is ID-utils and the associated
Emacs command "M-x gid RET".

However, I think "M-x find-grep-dired RET" will do, if you don't have
ID-utils installed.

Re: [commit] Deprecate remaining STREQ uses

[David Carlton]

On Mon, 24 Nov 2003 21:23:34 +0200, "Eli Zaretskii" <eliz@elta.co.il> said:

> I don't think simply replacing the macros with their expansion could
> introduce bugs.  If you don't trust your eyes and hands, perhaps
> Emacs's c-macro-expand command (or some other similar automated
> tool) could help.

Yeah, I was thinking that an automated tool would work well.  I was
thinking that just using keyboard macros might do the trick: get to
the start of STREQ, then delete that word, insert "(strcmp", go
forward a regexp, and insert "==0)" should be safe, no?  But I didn't
know about c-macro-expand; looks useful.

David Carlton
carlton@kealia.com

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Mon, 24 Nov 2003 12:06:24 -0800
> 
> I was thinking that just using keyboard macros might do the trick:

For such a simple job, it probably would.  But c-macro-expand is more
trustworthy, IMHO: it actually runs cpp and has provisions for you to
specify the same compiler switches as are used during an actual
compilation, so you don't run a risk of missing some obscure #define
somewhere.

> go forward a regexp

You probably meant to go forward a sexp.

Re: [commit] Deprecate remaining STREQ uses

[David Carlton]

On 25 Nov 2003 08:55:33 +0200, Eli Zaretskii <eliz@elta.co.il> said:
>> From: David Carlton <carlton@kealia.com>
>> Date: Mon, 24 Nov 2003 12:06:24 -0800
>> 
>> I was thinking that just using keyboard macros might do the trick:

> For such a simple job, it probably would.  But c-macro-expand is more
> trustworthy, IMHO: it actually runs cpp and has provisions for you to
> specify the same compiler switches as are used during an actual
> compilation, so you don't run a risk of missing some obscure #define
> somewhere.

Actually, in the case at hand, they would give different results, it
turns out!  The definition of STREQ isn't simply strcmp()==0 - there's
an optimization (or "optimization", perhaps) there as well.

>> go forward a regexp

> You probably meant to go forward a sexp.

Yup, that's what I meant to say, thanks.  Though what my fingers would
do is M-C-n, which seems to be bound to forward-list...

David Carlton
carlton@kealia.com

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> On 25 Nov 2003 08:55:33 +0200, Eli Zaretskii <eliz@elta.co.il> said:
> 
>>> From: David Carlton <carlton@kealia.com>
>>> Date: Mon, 24 Nov 2003 12:06:24 -0800
>>> 
>>> I was thinking that just using keyboard macros might do the trick:
> 
> 
>> For such a simple job, it probably would.  But c-macro-expand is more
>> trustworthy, IMHO: it actually runs cpp and has provisions for you to
>> specify the same compiler switches as are used during an actual
>> compilation, so you don't run a risk of missing some obscure #define
>> somewhere.
> 
> 
> Actually, in the case at hand, they would give different results, it
> turns out!  The definition of STREQ isn't simply strcmp()==0 - there's
> an optimization (or "optimization", perhaps) there as well.

You'll now appreciate my paranoia :-)

So, should the transformation be the strictly mechanical inline expansion:

   STREQ(a,b) =>  (*(a) == *(b) ? !strcmp ((a), (b)) : 0)

or also include a simplification leading to:

   STREQ(a,b) => (strcmp ((a), (b)) == 0)

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Daniel Jacobowitz]

On Tue, Nov 25, 2003 at 12:54:15PM -0500, Andrew Cagney wrote:
> >On 25 Nov 2003 08:55:33 +0200, Eli Zaretskii <eliz@elta.co.il> said:
> >
> >>>From: David Carlton <carlton@kealia.com>
> >>>Date: Mon, 24 Nov 2003 12:06:24 -0800
> >>>
> >>>I was thinking that just using keyboard macros might do the trick:
> >
> >
> >>For such a simple job, it probably would.  But c-macro-expand is more
> >>trustworthy, IMHO: it actually runs cpp and has provisions for you to
> >>specify the same compiler switches as are used during an actual
> >>compilation, so you don't run a risk of missing some obscure #define
> >>somewhere.
> >
> >
> >Actually, in the case at hand, they would give different results, it
> >turns out!  The definition of STREQ isn't simply strcmp()==0 - there's
> >an optimization (or "optimization", perhaps) there as well.
> 
> You'll now appreciate my paranoia :-)
> 
> So, should the transformation be the strictly mechanical inline expansion:
> 
>   STREQ(a,b) =>  (*(a) == *(b) ? !strcmp ((a), (b)) : 0)
> 
> or also include a simplification leading to:
> 
>   STREQ(a,b) => (strcmp ((a), (b)) == 0)

Personally, I recommend the latter - I think part of the motivation for
eliminating STREQ was to get rid of that extra test, right?  If you
want to do this mechanically, you can just change the definition of
STREQ first, of course.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [commit] Deprecate remaining STREQ uses

[David Carlton]

On Tue, 25 Nov 2003 12:57:22 -0500, Daniel Jacobowitz <drow@mvista.com> said:
> On Tue, Nov 25, 2003 at 12:54:15PM -0500, Andrew Cagney wrote:

>> So, should the transformation be the strictly mechanical inline expansion:
>> 
>> STREQ(a,b) =>  (*(a) == *(b) ? !strcmp ((a), (b)) : 0)
>> 
>> or also include a simplification leading to:
>> 
>> STREQ(a,b) => (strcmp ((a), (b)) == 0)

> If you want to do this mechanically, you can just change the
> definition of STREQ first, of course.

Good point!

David Carlton
carlton@kealia.com

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

>> You'll now appreciate my paranoia :-)
>> 
>> So, should the transformation be the strictly mechanical inline expansion:
>> 
>>   STREQ(a,b) =>  (*(a) == *(b) ? !strcmp ((a), (b)) : 0)
>> 
>> or also include a simplification leading to:
>> 
>>   STREQ(a,b) => (strcmp ((a), (b)) == 0)
> 
> 
> Personally, I recommend the latter - I think part of the motivation for
> eliminating STREQ was to get rid of that extra test, right?  If you
> want to do this mechanically, you can just change the definition of
> STREQ first, of course.

My question is somewhat retorical.  I'd expect everyone to express a 
preference for the latter.  What's needed is for people to recognize 
that such a transformation could potentially alter the program's 
behavior.  It shouldn't but if it does it's not my fault.

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Tue, 25 Nov 2003 13:42:33 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> What's needed is for people to recognize that such a transformation
> could potentially alter the program's behavior.

Not if you use c-macro-expand or a similar tool, it won't.

Anyway, I trust GDB developers, yourself included, to make such simple
changes without introducing bugs.

Re: [commit] Deprecate remaining STREQ uses

[David Carlton]

On Tue, 25 Nov 2003 12:54:15 -0500, Andrew Cagney <cagney@gnu.org> said:

> So, should the transformation be the strictly mechanical inline expansion:

>    STREQ(a,b) =>  (*(a) == *(b) ? !strcmp ((a), (b)) : 0)

> or also include a simplification leading to:

>    STREQ(a,b) => (strcmp ((a), (b)) == 0)

I would vote for the latter.  It should be easy to do mechanically via
keyboard macros, and it's how we would prefer the code to look.

David Carlton
carlton@kealia.com

Re: [commit] Deprecate remaining STREQ uses

[Kevin Buettner]

On Nov 25, 12:54pm, Andrew Cagney wrote:

> So, should the transformation be the strictly mechanical inline expansion:
> 
>    STREQ(a,b) =>  (*(a) == *(b) ? !strcmp ((a), (b)) : 0)
> 
> or also include a simplification leading to:
> 
>    STREQ(a,b) => (strcmp ((a), (b)) == 0)

The latter.  If you still want to do the former, you might as well
keep the macro.

Kevin

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Tue, 25 Nov 2003 12:54:15 -0500
> From: Andrew Cagney <cagney@gnu.org>
> > 
> > Actually, in the case at hand, they would give different results, it
> > turns out!  The definition of STREQ isn't simply strcmp()==0 - there's
> > an optimization (or "optimization", perhaps) there as well.
> 
> You'll now appreciate my paranoia :-)

So does Emacs ;-)

> So, should the transformation be the strictly mechanical inline expansion:
> 
>    STREQ(a,b) =>  (*(a) == *(b) ? !strcmp ((a), (b)) : 0)
> 
> or also include a simplification leading to:
> 
>    STREQ(a,b) => (strcmp ((a), (b)) == 0)

IIRC, we decided long ago that the so-called ``optimization'' in the
former macro definition was a waste of cycles.  So my recommendation
would be to use the latter.

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> From: David Carlton <carlton@kealia.com>
>> Date: Mon, 24 Nov 2003 12:06:24 -0800
>> 
>> I was thinking that just using keyboard macros might do the trick:
> 
> 
> For such a simple job, it probably would.  But c-macro-expand is more
> trustworthy, IMHO: it actually runs cpp and has provisions for you to
> specify the same compiler switches as are used during an actual
> compilation, so you don't run a risk of missing some obscure #define
> somewhere.

Is there a way, in EMACS, to pipe a section of code through a shell and 
then have that code re-inserted in place?

I've played with c-macro-expand but found the experience less than 
satisfying.  The text ends up in a separate window leaving me with an 
additional messy cut/paste step.

Andrew

PS: Steps will likely be:

- change streq[n] to sane equivalents
- re-indent rougly half of GDB
the output of cpp is messy, I'm going to need to re-indent it, which 
means I'm going to need to re-indent befor the event
- this to-be-determined step

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Fri, 05 Dec 2003 11:26:32 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> Is there a way, in EMACS, to pipe a section of code through a shell and 
> then have that code re-inserted in place?

There's a way in Emacs to do everything (well, perhaps except a cup
of coffee ;-).

You want "C-u M-|", I think.  See the doc string of
shell-command-on-region (bound to M-|) for more details.

> I've played with c-macro-expand but found the experience less than 
> satisfying.  The text ends up in a separate window leaving me with an 
> additional messy cut/paste step.

It sounds like you missed the documentation of c-macro-expand, which
says:

    c-macro-expand is an interactive autoloaded Lisp function in `cmacexp'.
    (c-macro-expand START END SUBST)

    Expand C macros in the region, using the C preprocessor.
    Normally display output in temp buffer, but
    prefix arg means replace the region with it.

Note the last sentence: it means that "C-u M-x c-macro-expand RET"
will replace the marked region with the results of the expansion.

> PS: Steps will likely be:
> 
> - change streq[n] to sane equivalents
> - re-indent rougly half of GDB
> the output of cpp is messy, I'm going to need to re-indent it, which 
> means I'm going to need to re-indent befor the event
> - this to-be-determined step

For reindenting, just mark the region and then type "C-M-\".

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> It sounds like you missed the documentation of c-macro-expand, which
> says:
> 
>     c-macro-expand is an interactive autoloaded Lisp function in `cmacexp'.
>     (c-macro-expand START END SUBST)
> 
>     Expand C macros in the region, using the C preprocessor.
>     Normally display output in temp buffer, but
>     prefix arg means replace the region with it.
> 
> Note the last sentence: it means that "C-u M-x c-macro-expand RET"
> will replace the marked region with the results of the expansion.

I found the documentation (needed it to set the variable that makes it 
prompt for the command arguments, and set the CPP to run :-) but could 
make neither head nor tails out of "prefix arg".

>> PS: Steps will likely be:
>> 
>> - change streq[n] to sane equivalents
>> - re-indent rougly half of GDB
>> the output of cpp is messy, I'm going to need to re-indent it, which 
>> means I'm going to need to re-indent befor the event
>> - this to-be-determined step
> 
> 
> For reindenting, just mark the region and then type "C-M-\".

It's the spaces between the paren that's the problem.  CPP turns:

	#define A(B,C) ((B) + (C))
	A(b,c)

into

	( ( b ) + ( c ) )

I'm hoping that indent will eat a few of the unnecessary spaces (the 
paren are a lost cause).

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Sat, 06 Dec 2003 09:08:57 -0500
> From: Andrew Cagney <cagney@gnu.org>
> > 
> >     Expand C macros in the region, using the C preprocessor.
> >     Normally display output in temp buffer, but
> >     prefix arg means replace the region with it.
> > 
> > Note the last sentence: it means that "C-u M-x c-macro-expand RET"
> > will replace the marked region with the results of the expansion.
> 
> I found the documentation (needed it to set the variable that makes it 
> prompt for the command arguments, and set the CPP to run :-) but could 
> make neither head nor tails out of "prefix arg".

The index search in the manual is your friend in such cases.  Once
you look at the Emacs manual in the *info* buffer, type the following
words of wisdom:

      i prefix arg RET

and you will land on the right section of the manual.

(The `i' command uses the index entries produced by @cindex, @findex
and the like.  Given a good indexing job, this command is IMHO the
most efficient method of getting to the information you need.  Perhaps
now you will better understand why I always ask for good index entries
for any new terminology added to the GDB manual. ;-)

> 	#define A(B,C) ((B) + (C))
> 	A(b,c)
> 
> into
> 
> 	( ( b ) + ( c ) )

Ah, in that case indenting will not help.  But something like
replacing all occurences of "( " with "(" and " )" with ")" should do
most of the work, I think.  Press `!', the exclam mark, when Emacs
asks for confirmation of the first replacement, and it will do the
rest of the replacements automatically without asking.

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

>> 	#define A(B,C) ((B) + (C))
>> 	A(b,c)
>> 
>> into
>> 
>> 	( ( b ) + ( c ) )
> 
> 
> Ah, in that case indenting will not help.  But something like
> replacing all occurences of "( " with "(" and " )" with ")" should do
> most of the work, I think.  Press `!', the exclam mark, when Emacs
> asks for confirmation of the first replacement, and it will do the
> rest of the replacements automatically without asking.

Or I can just run the code through gdb_indent.sh :-)  Since the result 
of the substitution also exceeds 80 columns, I figure using gdb_indent 
is easier :-)

Andrew

PS: One of your mailboxes is full.