Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uwmcsd1!lakesys!chad
From: chad@lakesys.UUCP (Chad Gibbons)
Newsgroups: comp.unix.xenix
Subject: sizes of objects in large model
Message-ID: <462@lakesys.UUCP>
Date: 14 Mar 89 19:40:43 GMT
Reply-To: chad@lakesys.UUCP (Chad Gibbons)
Distribution: usa
Organization: Lake Systems - Milwaukee, Wisconsin
Lines: 52


	I was having problems getting a program to work correctly under
SCO XENIX/286 V2.2.3.  The program works as expected on the 386 version
of the same OS.  It won't work because of same changes in pointer sizes
in the large model program.  The program, by the way, is Spacewar, if
that provides anyone any insight on how to get around this size problem.

	The progam relies on two different structures being the same
size.  Here are the definitions for the two structures:

struct uio {
	struct login far *uio_lgn;	/* user i/o pointer to login struct */
	char	uio_chrs[16];	/* user i/o characters */
};

struct uio2 {
	int	uio2sig;	/* signal, 0 for logon */
	short	uio2pid;	/* process-id of playsw */
	char	uio2tty[14];	/* ttyname for logon (signal 0 only) */
};

	In addition, the struct login is referenced.  Here is that:

struct login {
	short	ln_tty;		/* login terminal I/O channel */
	short	ln_playpid;	/* login play process pid */
	short	ln_readpid;	/* login read process pid */
	char	ln_name[8+1];	/* login name */
	char	*ln_term;	/* login terminal name */
				/* login trm. characteristics */
	char	*ln_tcm,*ln_tcl,*ln_tce,*ln_tso,*ln_tse;
	char	ln_rvslh;	/* login reverse low/high screen display */
	char	ln_iomode;	/* login I/O mode */
	char	ln_crft[12+1];	/* login craft name */
	idxptr	ln_play;	/* login is playing */
	char	ln_stat;	/* login status (major command) */
	char	*ln_substat;	/* login substatus (command dependent) */
	char	ln_input[79+1];	/* login input buffer */
};

	In a small model program, sizeof() reports 20 for both uio
structures.  In a large model (which the program must be to compile) the
first uio struct is 20, and the second, uio2, is 18.

	Any ideas on how to perhaps fix this?  In general, some
information on generting portable programs across memory models would be
helpful, not to mention any hints on how to get this monster program to
compiled.

Mail responses only, if you please.
-- 
D. Chadwick Gibbons, chad@lakesys.lakesys.com, ...!uunet!marque!lakesys!chad