|
do you have specific examples of this? I guess what we've always tried to
do is keep the communication between components at the interface level, so this
shouldn't be an issue. There is one in the XPCOM helper functions I found when removing the extra
exported symbols. I can go digging around and find it again but I wasn't too
worried about it since those functions were supposed to become a static library
in the near future. But how do we know if there are any others? There is no
simple way to find these.
It's not just the vtables that we have to worry about, it is also the
member variables. Any change to the binary footprint of the object will
make it fail.
Another example of this is a NS_NewXXX function that is inlined and then
does a 'new' internally instead of using XPCOM to create the object. There are
some of those in layout/content but I'm not sure if they are being used from
another DLL.
Cross DLL inlines are very dangerous. They need to all be located and
inspected. We should also isolate them so that they don't get changed by
accident.
|
- Re: Sorting out public vs private includes Alec Flett
- Re: Sorting out public vs private includes Jon Smirl
- Re: Sorting out public vs private includes Jon Smirl
- Re: Sorting out public vs private includes Alec Flett
- Re: Sorting out public vs private includes Jon Smirl
- Re: Sorting out public vs private includes Rick Parrish
- Re: Sorting out public vs private incl... Bradley Baetz
