On 1/14/2013 2:05 PM, Jesse Ruderman wrote:
Should we make debug builds check casts to (vtableful?) pointer types?
This could be done by adding and calling an "assert_cast" function, or
by adding a new "sanitizer" mode [6] to clang.
In order to keep our custom goop to a minimum, I don't think that an
in-code change to assert_cast would be good if we can accomplish the
same thing using the c++ compiler. We could just make this part of the
ASAN builds, right?
* Is it possible to 'query' vtableful objects by looking at vtable
pointers, like gdb does [7]? Or does this quickly become so
complicated that we might as well enable RTTI and use the same
mechanism as dynamic_cast?
I expect that what GDB does would be pretty expensive in terms of
inspecting the debuginfo and type tree. I'm pretty sure that enabling
RTTI for debug builds and use the dynamic_cast mechanism would be far
simpler and easier.
* Should we use specialized 'query' methods for nsIFrame, nsISupports,
and/or nsIClassInfo?
No.
* Should some of these checks be enabled in release builds?
The cost of RTTI (or other vtable-based methods) is very high. Normally
we use static_cast in places where perf is fairly critical. I don't
think we should consider adding this to release builds at this time.
* Would Gecko trigger many false positives?
The only time I can see this being an issue is when we cast the xptcall
stub class to an IDL interface, and we can probably whitelist the
xptcall stub. Otherwise, 3rd-party extension binaries are the only issue
I can see, and I don't think we'd be running these builds with 3rd-party
binaries anyway, right?
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
