On Sun, Aug 11, 2013 at 08:37:16PM +0200, Piñeiro wrote: > On 08/09/2013 11:02 PM, Trevor Saunders wrote: > > > >> I think that in the end we shouldn't worry too much about this in this > >> scope. I would maintain the temporal wrapper to the old method for this > >> bug (fwiw, bgo#705581) and think about the other problem from a more > >> general pov. I wouldn't block this patch for that issue. > > so its unclear to me how you do intend to decide if you need to use the > > old method now. > > The old method will be used as a fallback. That means that now the new > method will be called, and if fails, the old one will be used. More > about that on the thread "About the fallbacks related with the new > method get_text_for_offset, and deadlines"
well, that only works if you know it is always safe to look at the memory where AtkTextIface::get_text_for_offset lives, but I guess in this particular case you do actually know that (see below). > > However if you don't intend to break the abi you need > > to be sure the code that defines the atkobject you're dealing with was > > compiled against atk headers that defined the new method or you could > > end up reading some uninitialized memory and interpreting it as a > > function pointer. > > For that same reason, atk-bridge, that is the one that uses directly > atk, will pump up the dependency need for ATK. In the same way, in order > to not break the ABI, the new virtual method was added at the end of the > interface. In the general case I don't think adding at the end is enough to ensure you don't break the abi because other programs may put there own data immediately after the AtkTextIface vtable, and can rely on its size being constant in other places as well. However in this particular case I see that AtkTextIface::pad4 has been removed earlier this release cycle so adding a new method will just keep the vtable compatible with what it was before then. Trev > > BR > > -- > Alejandro Piñeiro Iglesias > > _______________________________________________ > gnome-accessibility-devel mailing list > gnome-accessibility-devel@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
