[Xcb] hidden-visibility and library size

[Josh Triplett]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20051229/4e3e7c10/signature.pgp