From owner-freebsd-hackers Thu Mar 16 09:22:48 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA13593 for hackers-outgoing; Thu, 16 Mar 1995 09:22:48 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA13587 for ; Thu, 16 Mar 1995 09:22:47 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA23508; Thu, 16 Mar 95 10:15:57 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503161715.AA23508@cs.weber.edu> Subject: Re: patches for X11R6?? To: dawes@physics.usyd.edu.au (David Dawes) Date: Thu, 16 Mar 95 10:15:56 MST Cc: ugen@netvision.net.il, hasty@netcom.com, dawes@physics.usyd.edu.au, hackers@FreeBSD.org In-Reply-To: <199503161146.AA01352@physics.su.oz.au> from "David Dawes" at Mar 16, 95 09:46:16 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > >Seems like has a bug in XFree 3.0. > >The bug is in definition of type Display (actually iy just > >left undefined) > > The details of the Display struct are supposed to be private (because > they are implementation dependent). For this reason, Display is > defined in Xlib.h as: > > typedef struct _XDisplay Display; > > and struct _XDisplay is left undefined (although it is defined in > Xlibint.h for internal use). This means that the only legal way to > refer to this type in a user program is as a pointer to it. > > If you compile with XLIB_ILLEGAL_ACCESS defined, then struct _XDisplay > is defined in Xlib.h. Code that requires this is not portable. Apparently there has been an opaquing of several structs in the latest X release, including the GC. I don't necessarily agree with all of the changes in this direction, since there is a significant loss in speed in the additional function call overhead for reading GC pixel value contents, for instance. If done on a SPARC processer, this in fact forces a push of the entire stack frame (SPARC does this each four calls), which is a *very* significant hit. 8-(. I can understand them not wanting you to write the values directly because of "server" side caching, but not wanting you to read them makes little or no sense. The "_ILLEGAL_ACCESS" for the GC is not backward compatible in any case, since there are (gratuitous) changes to the layout of the structure contents (elements are renamed). There is a major difference between interface abstraction and the rigorous enforcement of abstraction boundries. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.