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: [patch 2/2] Fix overload resolution of int* vs void*


>>>>> "Sami" == sami wagiaalla <swagiaal@redhat.com> writes:

Sami> I added one. The test attempts to make the conversion and fails as
Sami> expected.

Thanks for adding the tests, and for the explanations.

Sami> Having typed this out, I think POINTER_CONVERSION_BADNESS should be
Sami> renamed to BOOL_PTR_CONVERSION_BADNESS and given a rank of 3. And all
Sami> other conversions outlawed. I'll do this in and test it another
Sami> patch. This patch really only deals with the first clauses of the
Sami> nested switch statements.

Thanks.

Tom> GDB generally ignores access protection.  It seems like it ought to here
Tom> as well.

Sami> Hmm, I am worried that this will make overload resolution more
Sami> complicated, and lead to incorrect resolution.

Yeah, that makes sense to me.  But I still think ignoring it is probably
the best thing to do here.

Consider if you are stopped in a method or friend function of a derived
class.  In this case you do have access to the base -- so overload
resolution should work.  But with this patch, it will not.

Sami> I have no objection to
Sami> calling the inaccessible base function if the user casts the the type:

Casting is only ok if the base is accessible :)

Access bits are a real problem.  I don't know what to do in the long
run.  Consider something like "print obj.field".  If we strictly follow
C++, that can only work when "field" is accessible -- but in a debugger
that is basically useless.

Maybe we could come up with some heuristic for when it would be
acceptable and when it would not be.  And maybe overloading should be on
the "respect access" list -- but I think for the time being we should
still ignore it, until we have a good idea of what we want and the
capability to implement it correctly.

Aside from this final issue the patch looks ok to me.

Tom


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