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