On 01/16/2014 04:30 AM, Lukas Slebodnik wrote:
> 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
This is why I do not like the whole idea.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
