From: Tom Tromey <tromey@redhat.com>
To: sami wagiaalla <swagiaal@redhat.com>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org
Subject: Re: [patch 2/2] Fix overload resolution of int* vs void*
Date: Fri, 08 Oct 2010 22:54:00 -0000 [thread overview]
Message-ID: <m3tykwqor1.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4CAF889C.1080404@redhat.com> (sami wagiaalla's message of "Fri, 08 Oct 2010 17:09:48 -0400")
>>>>> "Sami" == sami wagiaalla <swagiaal@redhat.com> writes:
Sami> @@ -1886,6 +1886,14 @@ do_is_ancestor (struct type *base, struct type *dclass, int public)
Sami> if (class_types_same_p (base, dclass))
Sami> return 1;
Sami> + if ((TYPE_CODE (base) == TYPE_CODE_PTR
Sami> + && TYPE_CODE (dclass) == TYPE_CODE_PTR)
Sami> + || (TYPE_CODE (base) == TYPE_CODE_REF
Sami> + && TYPE_CODE (dclass) == TYPE_CODE_REF))
Sami> + return do_is_ancestor (TYPE_TARGET_TYPE (base),
Sami> + TYPE_TARGET_TYPE (dclass),
Sami> + public);
This seems strange to me. It ought to only be applicable at the
outermost call. But in that case, I think a wrapper function would be
more appropriate, so that do_is_ancestor has a single purpose.
Also, is this the right thing for the caller when there are multiple
pointers (like "Class ***")? Or do you intend to only strip a single
pointer?
Sami> + /* Resolve typedefs */
Sami> + if (TYPE_CODE (a) == TYPE_CODE_TYPEDEF)
Sami> + a = check_typedef (a);
Sami> + if (TYPE_CODE (b) == TYPE_CODE_TYPEDEF)
Sami> + b = check_typedef (b);
It is ok to call check_typedef unconditionally, but I see this is just
copied from rank_one_type.
Sami> + /* (b) pointer to ancestor-pointer conversion. */
Sami> + if (is_public_ancestor (parm, arg))
Sami> + return BASE_PTR_CONVERSION_BADNESS;
I am curious why you didn't just give POINTER_CONVERSION_BADNESS a new
value and instead introduced BASE_PTR_CONVERSION_BADNESS.
But then, I also don't understand the existing code that returns
POINTER_CONVERSION_BADNESS...
Also, why specifically is_public_ancestor and not is_ancestor?
I suppose this is an incremental patch -- still not truly correct with
regards to the distance-to-base problem, but an improvement over what
gdb currently does. This is fine, even great, but it is handy for
reviewers if you note that sort of thing in the patch explanation.
Sami> case TYPE_CODE_ARRAY:
Sami> - return rank_one_type (TYPE_TARGET_TYPE (parm),
Sami> - TYPE_TARGET_TYPE (arg));
Sami> + if (types_equal (TYPE_TARGET_TYPE (parm),
Sami> + TYPE_TARGET_TYPE (arg)))
Sami> + return 0;
Sami> + return INCOMPATIBLE_TYPE_BADNESS;
Do the new tests cover this case? I could not immediately tell.
Tom
next prev parent reply other threads:[~2010-10-08 22:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-30 15:24 [patch] " sami wagiaalla
2010-08-30 16:13 ` sami wagiaalla
2010-08-30 20:01 ` Tom Tromey
2010-10-08 18:39 ` [patch 1/2] " sami wagiaalla
2010-10-08 18:54 ` Tom Tromey
2010-10-08 19:35 ` sami wagiaalla
2010-10-08 21:30 ` Tom Tromey
2010-10-08 19:05 ` [patch 2/2] " sami wagiaalla
2010-10-08 20:46 ` Eli Zaretskii
2010-10-08 21:10 ` sami wagiaalla
2010-10-08 22:54 ` Tom Tromey [this message]
2010-10-12 20:01 ` sami wagiaalla
2010-10-12 20:41 ` Tom Tromey
2010-10-13 15:16 ` sami wagiaalla
2010-10-13 15:49 ` Tom Tromey
2010-10-13 18:29 ` sami wagiaalla
2010-10-15 14:46 ` sami wagiaalla
2010-10-15 22:48 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3tykwqor1.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=swagiaal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox