[patch] Code cleanup: objfile->name is never NULL

[patch] Code cleanup: objfile->name is never NULL

[Jan Kratochvil]

Hi,

there is some FUD in GDB code whether objfile->name can be NULL.  I haven't
found a way it could be.  Also a lot of GDB code already assumes it is not
NULL.

No regressions on {x86_64,x86_64-m32,i686}-fedora13-linux-gnu.

I will check it in later.


Thanks,
Jan


gdb/
2010-09-22  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Code cleanup.
	* objfiles.c (allocate_objfile) <objfile->name != NULL>: Remove.
	(free_objfile) <objfile->name != NULL>: Remove the conditional around
	xfree.
	* objfiles.h (struct objfile) <name>: New comment it is never NULL.
	* python/py-auto-load.c (auto_load_new_objfile) <!objfile->name>:
	Remove.
	* python/py-objfile.c (objfpy_get_filename) <obj->objfile->name>
	Remove the conditional.
	* python/py-progspace.c (pspy_get_filename) <objfile->name>: Likewise.

--- a/gdb/objfiles.c
+++ b/gdb/objfiles.c
@@ -214,10 +214,6 @@ allocate_objfile (bfd *abfd, int flags)
      region. */
 
   objfile->obfd = gdb_bfd_ref (abfd);
-  if (objfile->name != NULL)
-    {
-      xfree (objfile->name);
-    }
   if (abfd != NULL)
     {
       /* Look up the gdbarch associated with the BFD.  */
@@ -649,10 +645,7 @@ free_objfile (struct objfile *objfile)
 
   /* The last thing we do is free the objfile struct itself. */
 
-  if (objfile->name != NULL)
-    {
-      xfree (objfile->name);
-    }
+  xfree (objfile->name);
   if (objfile->global_psymbols.list)
     xfree (objfile->global_psymbols.list);
   if (objfile->static_psymbols.list)
--- a/gdb/objfiles.h
+++ b/gdb/objfiles.h
@@ -188,8 +188,8 @@ struct objfile
 
     struct objfile *next;
 
-    /* The object file's name, tilde-expanded and absolute.
-       Malloc'd; free it if you free this struct.  */
+    /* The object file's name, tilde-expanded and absolute.  Malloc'd; free it
+       if you free this struct.  This pointer is never NULL.  */
 
     char *name;
 
--- a/gdb/python/py-auto-load.c
+++ b/gdb/python/py-auto-load.c
@@ -395,8 +395,6 @@ auto_load_new_objfile (struct objfile *objfile)
       clear_section_scripts ();
       return;
     }
-  if (!objfile->name)
-    return;
 
   load_auto_scripts_for_objfile (objfile);
 }
--- a/gdb/python/py-objfile.c
+++ b/gdb/python/py-objfile.c
@@ -46,7 +46,7 @@ objfpy_get_filename (PyObject *self, void *closure)
 {
   objfile_object *obj = (objfile_object *) self;
 
-  if (obj->objfile && obj->objfile->name)
+  if (obj->objfile)
     return PyString_Decode (obj->objfile->name, strlen (obj->objfile->name),
 			    host_charset (), NULL);
   Py_RETURN_NONE;
--- a/gdb/python/py-progspace.c
+++ b/gdb/python/py-progspace.c
@@ -52,7 +52,7 @@ pspy_get_filename (PyObject *self, void *closure)
     {
       struct objfile *objfile = obj->pspace->symfile_object_file;
 
-      if (objfile && objfile->name)
+      if (objfile)
 	return PyString_Decode (objfile->name, strlen (objfile->name),
 				host_charset (), NULL);
     }

Re: [patch] Code cleanup: objfile->name is never NULL

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> there is some FUD in GDB code whether objfile->name can be NULL.  I
Jan> haven't found a way it could be.  Also a lot of GDB code already
Jan> assumes it is not NULL.

I agree with this patch.

Jan> -  if (!objfile->name)
Jan> -    return;
 
Jan>    load_auto_scripts_for_objfile (objfile);

This part made me realize that we should probably have some kind of "is
a file" flag on the objfile, to avoid trying to load files relative to a
phony name like "<<anonymous objfile>>".

Tom

Re: [patch] Code cleanup: objfile->name is never NULL

[Jan Kratochvil]

On Wed, 22 Sep 2010 21:42:45 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> 
> Jan> there is some FUD in GDB code whether objfile->name can be NULL.  I
> Jan> haven't found a way it could be.  Also a lot of GDB code already
> Jan> assumes it is not NULL.
> 
> I agree with this patch.

Checked-in:
	http://sourceware.org/ml/gdb-cvs/2010-09/msg00137.html


Thanks,
Jan