Binary compatibility summary 4.5.1->4.5.2

[George Kiagiadakis]

On Tue, Oct 5, 2010 at 11:27 PM, Parker Coates
<parker.coates at kdemail.net> wrote:
> On Tue, Oct 5, 2010 at 16:09, Modestas Vainius wrote:
>> On antradienis 05 Spalis 2010 15:06:41 Lubos Lunak wrote:
>>>  The complete check is at http://ktown.kde.org/~seli/abi/ . If there are
>>> any public libraries not included, please say so. Also note that in this
>>> case there are few harmless false positives caused by transitioning to
>>> Qt4.7 at the same time.
>>>
>>>  There is one BIC problem, in kdebase/workspace:
>>> libweather_ion removes
>>> IonInterface::resetCompleted ( IonInterface::IonInterface* p1, bool p2 )
>>
>> Is removal of signals BIC? If I understand correctly, code using that signal
>> may lose some functionality but it won't crash (nor rebuild of the code would
>> change anything) because connection to signals happens entirely at run time. I
>> have also seen signal removals in kdelibs and nobody complained then.
>
> Signals are just private methods with fancy wrapping. So I'm pretty
> sure removing them is a BIC.
>
> For example if class B is a friend of class A, then B can emit A's
> signals. In the very unlikely case that A removed a signal, but B was
> not updated, B trying to emit the signal would obviously cause major
> issues.

Removing private methods is not really BIC. As you say, for an
external class to use this method, the library class needs to declare
the other as friend, which is highly unlikely to happen in any sane
piece of code ;)

However, signals are actually protected, which means that subclasses
can emit them without being friends (and emiting them is not done with
any runtime magic, it's just a normal C++ function call), so yes, this
is BIC.