From owner-freebsd-hackers Thu Mar 16 11:12:47 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA23780 for hackers-outgoing; Thu, 16 Mar 1995 11:12:47 -0800 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA23774 for ; Thu, 16 Mar 1995 11:12:46 -0800 Received: from fedora.x.org by expo.x.org id AA27517; Thu, 16 Mar 95 14:12:10 -0500 Received: by fedora.x.org id AA12240; Thu, 16 Mar 1995 14:12:09 -0500 Message-Id: <9503161912.AA12240@fedora.x.org> To: hackers@FreeBSD.org Subject: Re: patches for X11R6?? In-Reply-To: Your message of "Thu, 16 Mar 1995 10:15:56 MST." <9503161715.AA23508@cs.weber.edu> Date: Thu, 16 Mar 1995 14:12:09 EST From: "Kaleb S. KEITHLEY" Sender: hackers-owner@FreeBSD.org Precedence: bulk >> 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'm not sure what those would be. Would you care to elaborate? >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-(. Considering it takes about 0.5 usec to make a one argument function call on a SPARC 10 with debug turned on, and about 0.2 usec with optimization turned on, I think you'd have to make a lot of GC function calls to incur a significant hit. I would argue that you're doing something wrong if you're retrieving data from the GC-struct frequently. I'm sure you can think of alternative strategies to avoid excessive function calls if that's really your performance bottleneck. >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. ``"server" side caching''? In the client? >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). X11 is a standard just like ANSI/ISO C and IEEE POSIX. The X Consortium members specified the GC and Display structures, and the Sample Implementation is a reflection of the standard. The changes were not gratuitous, they were made with the full knowledge and approval of the members of the X Consortium. >There is a major difference between interface abstraction and the >rigorous enforcement of abstraction boundries. Which is not a valid rationalization for leaving a bug in the sample implementation; especially if it's a bug that encourages people to write inherently non-portable programs. The R5 Xlib.h warned people not to use the fields in these structures, and these fields aren't listed in the documentation. The only way they could have found out about them was by reading the header file, so if they've been writing non-portable programs, they can't say they weren't warned. -- Kaleb KEITHLEY X Consortium