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

Dmitri Pal dpal at redhat.com
Wed Jan 15 00:37:40 UTC 2014


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?

> 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
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the sssd-devel mailing list