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?