[Xcb] hidden-visibility and library size

[Vincent Torri]

So, what is decided ?

1) using -fvisibility=hidden during compilation and putting a "default"
attribute in front of all the exported functions

or

2) putting a "hidden" attribute in front of the non-exported functions ?

the solution 1) is not so hard, as most of the job would be made by
xsltproc.

in both cases, it's not a big deal (I've already made the m4 function,
which must be modified a bit according to what is chosen, and adding some
attributes), but a decision should be taken, imho.

Vincent


On Thu, 29 Dec 2005, Josh Triplett wrote:

> Jamey Sharp wrote:
> > On Tue, Dec 27, 2005 at 09:05:20PM -0800, Josh Triplett wrote:
> >>Jamey Sharp wrote:
> >>>I think setting visibility hidden by default is the wrong choice here.
> >>>Instead of setting any compile flags or touching any public header
> >>>files, just fix xcbint.h so that everything there is marked either
> >>>hidden or internal.
> >>
> >>I tend to disagree.  Hidden by default means that if you forget to mark
> >>something as visible, it stays hidden, meaning that it is far easier to
> >>unintentionally make a symbol hidden than to unintentionally make a
> >>symbol visible.  The consequence of an unintentionally hidden symbol is
> >>easy to notice (since applications will fail to compile), and the fix is
> >>simply to make it visible, which doesn't affect library backward
> >>compatibility.  The consequence of an unintentionally visible symbol is
> >>hard to notice (and might not be noticed until people start using it),
> >>and the fix causes a backward-incompatible change to the library.  I
> >>think we should have symbols hidden by default, and mark the public API
> >>as non-hidden.
> >
> > What do you think of using the visibility pragma instead, and marking
> > all of xcbint.h hidden or internal that way? We already use GCC warnings
> > to check that all functions either are static or have a prototype
> > somewhere, which guarantees that the functions that need hidden
> > visibility are all present in xcbint.h.
>
> Either approach is fine as long as we mark all the hidden symbols hidden
> and all the public symbols public.  I was just suggesting why one
> approach might help reach that goal more easily; however, any approach
> which achieves that goal is fine by me.
>
> > Anyway I'm not sure I agree with your assessment. Visibility doesn't
> > work on most compilers in use today anyway, so its value for giving
> > people compiler errors is pretty limited, and failure to set default
> > visibility may well not be noticed quickly leading to surprises later.
> > (I'm still using GCC 3.4.5 most of the time, for example, so I'm
> > unlikely to notice bugs here.)
>
> testing is using 4.0 now; are you explicitly invoking gcc-3.4?  Why?
>
> As for the issue of non-uniform support, it doesn't seem any different
> than the fact that GCC 4.0 has a lot more warnings than GCC 3.4; using a
> newer compiler will find some bugs that an older one won't.
>
> > In contrast, by definition, the public API for a C library is exactly
> > the declarations in header files installed on the system, and if some
> > idiot goes to the trouble of installing xcbint.h themselves or copying
> > an internal prototype into their program, they deserve whatever they
> > get. I don't think the internal API needs any more protection than that.
>
> I guess I figured that non-public symbols shouldn't be exported from a
> library at all; perhaps I'm overly cautious due to current use of Xlib.
> :)  I also figure that given the small size of XCB, and the tendency of
> various large and popular projects (<cough>Mozilla</cough>,
> <hack>OpenOffice.org</hack>) to incorporate libraries directly into
> their tree rather than using installed versions (and thus just using
> path/to/internal/xcb/include rather than $prefix/include), such projects
> might start using xcbint.h anyway since it would just be another
> #include away.  ("Oh, I just need this one useful function, *hack hack
> hack*.")
>
> Of course, marking everything in xcbint.h as non-visible would most
> likely solve that problem just as well.
>
> > In short, I think visibility is only useful as an optimization. Any
> > policy like "hidden by default" that makes it harder to produce a
> > library that operates correctly, just for the sake of an optimization,
> > is wrong.
>
> I do agree that if visibility is just an optimization, "visible by
> default" is probably the better alternative.  I just suspect that it has
> some value as an error-checking aid as well.
>
> However, again, as long as all the non-public symbols get marked as
> such, the effect is the same either way.
>
> - Josh Triplett
>