[SSSD] [PATCH][ding_libs] Add version symbol files

Lukas Slebodnik lslebodn at redhat.com
Wed Jan 15 07:37:15 UTC 2014


On (14/01/14 19:37), Dmitri Pal wrote:
>On 01/14/2014 01:46 PM, Lukas Slebodnik wrote:
>> On (13/01/14 16:46), Simo Sorce wrote:
>>> On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
>>>> On 01/13/2014 02:53 PM, Stephen Gallagher wrote:
>>>>> On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
>>>>>> ehlo,
>>>>>> attached patch addresses ticket #2193
>>>>>> I have just a question about refarray/libref_array.sym There is
>>>>>> extern function ref_array_debug, which is not defined in public
>>>>>> header file (not exposed in public API), but it is used in
>>>>>> ref_array unit tests. It needs to be in global section because
>>>>>> linker with fail to find symbol. Should I add any comment to the
>>>>>> file libref_array.sym or does anyone better solution?
>>>>>
>>>>> If this isn't a public API and isn't used except by the unit test, it
>>>>> should probably not be built as part of the library. It should
>>>>> probably be part of the unit test.
>>>> IMO this is conceptually wrong.
>>>> Unit test emulates external use of the library. Unit test uses only
>>>> public header and not private headers if any.
>>>> If we put debug function in the unit test we will expose internal of the
>>>> library that should not be know outside.
>>>> I always view unit tests as example of use. If we show that it is OK to
>>>> include private headers people would include private headers and try to
>>>> access internal structures directly.
>>> Sorry but I see a few issues with this argument.
>>>
>>> You say that unit tests only use the public API, the  you proceed and
>>> use an undisclosed API that is not made available through the public
>>> header files ? Isn't this contradictory ?
>>>
>>> Also I see nothing wrong in accessing private data via unit tests, I
>>> never heard anyone have the expectation that unit tests are actually
>>> examples to follow.
>>>
>>>> Putting it into a separate module is probably the cleanest solution but
>>>> IMO too much overhead.
>>> A separate shared object would be too much, but you can statically link
>>> the function in the unit tests.
>> Static linking would work with unit test, but function ref_array_reset is also
>
>you mean ref_array_debug, right?
>
Yes, I meant ref_array_debug. (copy&paste problem :-)

BTW. It is already exposed in libref_array.so
bash$ objdump -T /usr/lib64/libref_array.so | grep ref_array_debug
0000000000001300 g    DF .text  0000000000000176  Base        ref_array_debug
                ^^^
             g means global

>> used in the file ini/ini_valueobj.c (I forgot to mention it in the 1st mail)
>>
>>   1065  #ifdef HAVE_TRACE
>>   1066
>>   1067          ref_array_debug(vo->raw_lines, 0);
>>   1068          ref_array_debug(vo->raw_lengths, 1);
>>   1069  #endif
>
>yes it is used in the other "debug" situation.
>This is exactly the situation that I mentioned in the other mail: "use
>private functions from the library at your own risk".
>I acknowledge the risk, this is why it is if-defed not just not called
>based on an if() statement.
>

LS



More information about the sssd-devel mailing list