marshall@software.ORG (Eric Marshall) (12/17/87)
Why is it that the components of the XPoint struct are
shorts, the x and y values taken as parameters to Xlib calls are
int's, and the height and width taken by Xlib calls are unsigned
ints (especially why unsigned)? Why is there not a single object
type to reflect the display size? Thanks in advance.
Eric Marshall
Software Productivity Consortium
1880 North Campus Commons Drive
Reston, VA 22091
(703) 391-1838
CSNET: marshall@software.org
ARPANET: marshall%software.org@relay.cs.net OR
@relay.cs.net:marshall@software.orgjg@jumbo.dec.com (Jim Gettys) (12/19/87)
In article <8712180210.AA29937@ATHENA.MIT.EDU> marshall@software.ORG (Eric Marshall) writes: > > Why is it that the components of the XPoint struct are >shorts, The protocol request sizes for a point are 16 bits/coordinate. Since most machines in use short = 16 bits and the fact that some implementations will use shared memory for transport, I wanted to be able to move XPoint stuctures between client and server without having to reformat every piece of data for most implementations. Same thing goes for other structures used in poly calls. These are the only places in the interface where shorts are used, and is an efficiency hack for very high performance implementations, where converting each coordinate is much too slow. Some hardware can draw points/lines, etc at rediculous speeds. >the x and y values taken as parameters to Xlib calls are >int's, and the height and width taken by Xlib calls are unsigned >ints (especially why unsigned)? Coordinates can certainly be negative; a line can certainly start at -10, -10, for example. In X, height and width can only be unsigned; lint will then be kind enough to find certain kinds of bugs in your program when you attempt to assign signed quantities to the values. >Why is there not a single object >type to reflect the display size? Thanks in advance. I'm not quite sure what you mean here. The screen size is available in the screen structures. > > >Eric Marshall >Software Productivity Consortium >1880 North Campus Commons Drive >Reston, VA 22091 >(703) 391-1838 > >CSNET: marshall@software.org >ARPANET: marshall%software.org@relay.cs.net OR > @relay.cs.net:marshall@software.org
newman@athena.mit.edu (Ron Newman) (12/19/87)
In article <8712180210.AA29937@ATHENA.MIT.EDU> marshall@software.ORG (Eric Marshall) writes: > > Why is it that the components of the XPoint struct are >shorts, the x and y values taken as parameters to Xlib calls are >int's, and the height and width taken by Xlib calls are unsigned >ints (especially why unsigned)? Why is there not a single object >type to reflect the display size? Thanks in advance. > The components of the XPoint structure are signed shorts because most compilers treat shorts as 16-bit entities, and the protocol representation of a POINT is [x, y: INT16], i.e. two 16-bit signed integers. Since a client program may pass a large number of XPoints to XDrawPoints, Xlib wants to put the client's data directly on the wire, without having to reformat it from (possibly 32-bit) "int" to 16-bit "short". For similar reasons, the "x" and "y" components of XSegment, XRectangle, and XArc are declared to be signed shorts. The "width" and "height" components of XRectangle and XArc are declared as unsigned shorts because the protocol declares them to be CARD16, which for most C compilers is an unsigned short. The "x" and "y" arguments to Xlib calls are "int"s because (a) they are signed values, and (b) there would be no point in declaring them to be shorts, since the C language would treat promote them ints anyway. The "height" and "width" arguments to Xlib calls are "unsigned int"s because the protocol specifies them to be CARD16, i.e. 16-bit unsigned integers. If the parameters were declared as "int" on a machine with 16-bit "int"s, you would lose the ability to use values between 32768 and 65535. /Ron Newman (one of the Xlib implementors)
oj@apollo.uucp (Ellis Oliver Jones) (12/20/87)
In article <8712180210.AA29937@ATHENA.MIT.EDU> marshall@software.ORG (Eric Marshall) writes: >Why are the components of the XPoint struct >shorts, the x and y...parameters to Xlib calls int's... Why, indeed? This problem shows up for XSegment, XRectangle, and XArc structures as well. I imagine it's because of the way most C compilers pass scalar arguments (on the stack, by value, always promoting to longword). It is confusing, however. It's too bad it's too late to make major Xlib changes. >...height and width...are unsigned ints (especially why unsigned)? In this case, there is a good reason. width and height parameters *must* *be* *positive!* The impact of this is that you always must specify the upper left corner for rectangles and arc-bounding-boxes.