[SSSD] [PATCH][ding_libs] Collection: Fix typo in function declarations

Jakub Hrozek jhrozek at redhat.com
Wed Feb 19 10:18:01 UTC 2014


On Mon, Jan 13, 2014 at 09:02:00AM -0500, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/13/2014 05:45 AM, Lukas Slebodnik wrote:
> > ehlo,
> > 
> > While I was working on symbol maps for ding_libs, I found out two
> > declarations of function were misspelled in the public header file.
> > It looks like nobody used this function, because symbols in library
> > are correct
> > 
> > [root at unused-4-233 ~]# objdump -T /usr/lib64/libcollection.so |
> > grep col_insert_unsi 0000000000006d50 g    DF .text
> > 000000000000003b  Base col_insert_unsigned_property_with_ref 
> > 0000000000006af0 g    DF .text  000000000000003a  Base
> > col_insert_unsigned_property
> > 
> > Problem is fixed with simple replacement s/ng/gn/
> > 
> > I can see a problem. I am not sure if we should bump SONAME, 
> > because ABI of library is not changed, but API is technically 
> > changed in imcompatible way (two functions were removed and two
> > functions were added). It looks like nobody used this functions,
> > because it is impossible to link program with wrong declaration.
> > 
> 
> 
> Yeah, it's an interesting case, but I'm going to say that we should
> just treat it as a function addition, not a removal. My thought process:
> 
> - From an ABI perspective, no function definitions have been changed.
> This is because the exposed functions in the library itself have not
> been changed.
> 
> - From an API perspective, a function definition with no implementation
> was removed, but this has zero effect on the linkage with other
> applications.
> 
> So I'd treat this like "an internal private function was just promoted
> to being a public function". So for handling the version-info, it
> should be just treated as a new function and leave it at that. (So,
> effective result: collection's version info changes from 3:0:1 to 4:0:2
> 
> 
> Ack, with that correction.

Pushed to master, version info will be dealt with separately.



More information about the sssd-devel mailing list