CVS Update: xc (branch: trunk)

Daniel Stone daniel at fooishbar.org
Tue Feb 1 01:50:10 PST 2005


On Tue, Feb 01, 2005 at 12:41:58AM -0800, Keith Packard wrote:
> Around 17 o'clock on Feb 1, Daniel Stone wrote:
> > I made this change so we could actually delineate between what was
> > and was not private API.  I don't know what the rationale for intruding
> > on another library's allegedly private API was in the first place, but
> > I just made it official: either it should be public, or libSM must not
> > rely on it.
> 
> I haven't done this for other public-but-unadvertised symbols as used in 
> Xlib; I'm not sure it's strictly necessary.

Well, it depends.  If it's in external Xlib headers, sure, but this one
was not in any external headers, and the comment in SM was 'yes, this is
private API, so this is why we typedef it here'.  I think it was pretty
clearly not public API.

Xt is also a nightmare here -- last I saw, Xaw requires a lot of FooI.h
headers from Xt, which are the Xt designation for internal, AIUI.

> It does look "nicer" to have all of the public APIs not represented with 
> secret underscore prefixes, but I think we can take this too far.

Agreed.

> Anyone else care if the "public" API includes a bunch of random underscore 
> prefixed symbols which are essentially accidentally shared symbols?

No.  That's just bad taste, unlike the rest of Xlib ... :)

I think the better option would be to, if you had symbol _FooBar,
introduce a new (public) symbol FooBar, and make _FooBar do nothing
but call FooBar; a macro will not be sufficient here since it will break
with pre-compiled programs.  Mark _FooBar as deprecated, and instantly
feel better about yourself.

I would love to go through all of xlibs with the gcc 'hidden' attribute
some day.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20050201/51384606/attachment.pgp>


More information about the xorg mailing list