Bug 30008

Summary: XOrg 7.5 breaks XShm API
Product: xorg Reporter: Matthew Mondor <mm_lists>
Component: Lib/otherAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium    
Version: 7.5 (2009.10)   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Suggested change none

Description Matthew Mondor 2010-09-03 22:00:54 UTC
Created attachment 38416 [details] [review]
Suggested change

The XOrg 7.5 release contains the following change:

http://cgit.freedesktop.org/xorg/proto/xextproto/commit/?id=c63abdd1eb7bc1d8ae4e25073ef2f29d94991e2b

However, this change does not include a change to the XShm.3 manual page,
and breaks API compatibility where it is assumed that including XShm.h
includes the prototype definitions of the related library functions.

I understand the decision to clean up the code by separating the prototypes
to the shmproto.h file, but shouldn't XShm.h then also implicitely include
shmproto.h?

Otherwise software making use of the MIT-SHM extension need to be modified
to account for pre-7.5 XFree86+XOrg as well as post-7.5.  I assume that
since XShm.3 does not document the change, breaking the API was unintended.

Thank you.
Comment 1 Alan Coopersmith 2010-09-03 22:05:46 UTC
As shown in the diff you linked to, shmproto.h does not contain 
prototypes for any library functions - it only contains the structures 
for the wire protocol, which are used by the library & the server, but 
not callers to the library.

I don't see how API compatibility is broken or what benefit this
proposed patch would bring.
Comment 2 Matthew Mondor 2010-09-03 23:33:10 UTC
On Fri,  3 Sep 2010 22:05:47 -0700 (PDT)
bugzilla-daemon@freedesktop.org wrote:

> --- Comment #1 from Alan Coopersmith <alan.coopersmith@oracle.com> 2010-09-03 22:05:46 PDT ---
> As shown in the diff you linked to, shmproto.h does not contain 
> prototypes for any library functions - it only contains the structures 
> for the wire protocol, which are used by the library & the server, but 
> not callers to the library.

Thanks for the quick reply.

You're actually right, and I noticed that the application in question
broke on X_ShmAttach which it used to detect the X error code type in
an error handler.

Somehow because of the header name (shmproto.h) and the very scattered
minutes I could put into finding out and submitting PRs I assumed the
problem was with a missing function prototype (proto evidently meaning
protocol here).

After looking at various package-specific bug reports related to
this split, I noticed that some OSs decided to add that implicit
include (when I proposed this for another OS some admited it was a
problem but that this fix would need upstream support), while some
packages were also "fixed" with OS-specific package system ad-hoc
patches such as:

/* Ugh */
#define X_ShmAttach 1
#endif

or

/* Appears reasonable but unfortunately still needs a patch */
#ifndef X_ShmAttach
#include <shmproto.h>
#endif

or simply

/*
 * Breaks builds on older XOrg, usually found on stable releases or on
 * less mainstream hardware/OSs for which upgrading include merges of
 * non-upstream-integrated patches
 */
#include <XShm.h>
#include <shmproto.h>


If it is definitive to keep the current state of things as-is, I will
instead propose fixes around the #ifndef X_ShmAttach for use as
third-party package patches on packages that break on 7.5 until the
upstream of the source provide their own fix around the issue.

Thanks

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.