On (15/01/14 14:57), Dmitri Pal wrote:
>On 01/15/2014 02:37 AM, Lukas Slebodnik wrote:
>> 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
>
>
>My assumption was always always that if the entry point is in public
>header, then it is public.
>If not it is not.
>
>ref_array.h which defines public interface does not deliberately list
>this function as public thus whether it is global or not really does not
>matter. It not public.
>
>2c.
Linker knows nothing about header file. It works only with
object modules (*.o). By default, it can distinguish only according to modifier
(static vs extern)
Another options is to use attribute visibility eg.
__attribute__ ((visibility ("hidden")));
__attribute__ ((visibility ("default")));
We decided to use 3rd option: version script
https://fedorahosted.org/sssd/ticket/2193
ftp://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html
LS
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
