Re: Handling macro change in an exported library header
* Nikita Youshchenko <yoush@debian.org> [080626 11:51]:
> To fix #486693, I need to apply a patch that changes #define'd macro in an
> exported library header.
>
> The pattern is:
>
> extern int foo(char *param1, int param2);
> #define bar(param) foo(param, expr(param))
>
> and changed thing is expr(param)
>
> Looks like binary interface of the shared library does not change, however
> strictly saying any user of the library that uses bar() macro needs to
> recompile his code.
I think the relavant questions are: what is semantically changing:
1) Library keeps the behaviour, headers change, code using the headers
must change because now the macro means something else
-> ABI (and thus soname) kept, API changes
(I do not know if there is a reasonable way packaging-wise to deal
with this, perhaps renaming the -dev package might be sensible,
depending on the impact).
2) Library keeps the behaviour, headers change, but intended behaviour
does not change (i.e. fixing some bug):
-> ABI and API stay, programs using the library may need an binNMU
to actually use the bugfix.
(Dato's mail indicates that is the case here.)
3) Library changes behaviour, headers adopted to get the original
behaviour when using the define.
For example function now wants an argument now one bigger or
smaller to mean the same.
-> ABI changes, and API too (unless using the symbol directly
is made impossible somehow).
-> soname bump needed (IMHO)
Where "changes behaviour" might be a bit tricky. Here it means "changes
meaning of the arguments". Where "before this argument = 0 meant
segfault now it means what was always in the documention" is not a
change of behaviour on that sense, but "before it was the length without
terminator, not it is the length with terminator" is a change.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
Reply to: