This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: fix PR gdb/2489


On Tuesday 03 February 2009 00:59:46, Tom Tromey wrote:
> Pedro> + ?for (i = TYPE_NFN_FIELDS (type) - 1; i >=0; --i)
> Pedro> + ? ?{
> Pedro> + ? ? ?char *name = TYPE_FN_FIELDLIST_NAME (type, i);
> Pedro> + ? ? ?if (name && ! strncmp (name, fieldname, namelen))
> Pedro> + ? ? ? {
> Pedro> + ? ? ? ? if (!type_name)
> Pedro> + ? ? ? ? ? type_name = type_name_no_tag (type);
> Pedro> + ? ? ? ? /* Omit constructors from the completion list. ?*/
> Pedro> + ? ? ? ? if (strcmp (type_name, name))
> Pedro> + ? ? ? ? ? {
> 
> Pedro> Can type_name ever be NULL here then?
> 
> The reason for the check here is that we compute type_name the first
> time we need it. ?It is initialized to NULL, but only set once.

Oh, sorry, I guess I wasn't clear.  I meant after the
type_name_no_tag call, at the strcmp line.

I mainly asked due to this:

 /* Return a typename for a struct/union/enum type without "struct ",
    "union ", or "enum ".  If the type has a NULL name, return NULL.  */

                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 char *
 type_name_no_tag (const struct type *type)
 {
   if (TYPE_TAG_NAME (type) != NULL)
     return TYPE_TAG_NAME (type);

   /* Is there code which expects this to return the name if there is
      no tag name?  My guess is that this is mainly used for C++ in
      cases where the two will always be the same.  */
   return TYPE_NAME (type);
 }

I don't know if that can happen here.  That was also the reason I
suggested an annonymous struct/class test.

On Tuesday 03 February 2009 00:59:46, Tom Tromey wrote:
> Pedro> (I wish we had a function we could call that abstracted and
> Pedro> made easier to write/read these completion tests.)
> 
> I rewrote the tests to use the "complete" command rather than sending
> a TAB.  This makes them much simpler.
> 

Indeed!  Much nicer.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]