Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 alpha 4/15/85; site cbosgd.UUCP Path: utzoo!watmath!clyde!cbosgd!mark From: mark@cbosgd.UUCP (Mark Horton) Newsgroups: net.unix-wizards,net.micro.pc Subject: Re: Xenix286 Wonders, Bugs, and Patches... Message-ID: <1143@cbosgd.UUCP> Date: Mon, 6-May-85 14:06:10 EDT Article-I.D.: cbosgd.1143 Posted: Mon May 6 14:06:10 1985 Date-Received: Wed, 8-May-85 01:43:44 EDT References: <168@medstar.UUCP> <2158@sun.uucp> Organization: AT&T Bell Laboratories, Columbus, Oh Lines: 61 Xref: watmath net.unix-wizards:13084 net.micro.pc:3884 In article <2158@sun.uucp> guy@sun.uucp (Guy Harris) writes: > >> exec() doesn't always work with the large model due to NULL being >> placed at the end of the arg list instead of (char *)NULL. This is a >> programmer problem more than a bug. >> >> system() doesn't work in the large model if the si register is >> non-zero. This is due to the exec() error above. They used NULL >> instead of (char *) NULL... > >The former is not at all a bug. *Good* programmers know to cast null >pointers properly. Other programmers write code that breaks on all the >machines out there with 16-bit "int"s and > 16-bit pointers... Sorry, Guy, I wish it were that simple. Get out your Unix Programmer's Manual and look up EXECL(3) (or EXEC(2) on System III/V). You'll notice that the DOCUMENTED FORM of the execl call says to pass a zero. Not a (char *) 0. Just a plain old 0. This worked fine on the PDP-11 and the VAX, but just in the last few years people have discovered that this single property of UNIX won't work on a machine with pointers that are bigger than integers. This includes some 68K implementations (although most, including Sun, provide 32 bit integers, presumably this is one reason why) and anything using the large model on an 8086 family machine. Of course, the fix is easy, just cast the 0 to (char *), but there is a lot of code out there that doesn't do this. Also, if you make the cast, you have to worry about what happens if your code is run on a machine with big integers and small pointers that didn't change the interface! I wonder what the /usr/group standard and the System V standard recently published say? >> stty/gtty : >> >> If one passes the sgttyb struct to stty that came from gtty, the >> echoe bit will be cleared. > >By your mention of "echoe", I presume Xenix 286 is System III or V >compatible. If so, you should *NOT* be using "stty" or "gtty"! They are >implemented only as, to quote the comment in the code, a "compatibility >aide"(sic). They are backwards compatible NOT with V7, but with UNIX/TS >1.0. UNIX/TS 1.0 didn't support "echoe" (i.e., CRT rubout), but then >neither did V7; as such, AT&T decided to have "stty" clear the "echoe" bit >(rather than leaving it alone). V7 terminal "ioctl"s will NOT work under >System III/V's tty driver, so programs written for V7 which use "stty" or >"gtty" have to be rewritten; programs written for UNIX/TS 1.0 should be >rewritten so that, among other things, they preserve the setting of the >ECHOE bit. You mean UNIX/TS 2.0; 1.0 was released to the public as PWB 1.0. My impression of Xenix was that they had enhanced the stty emulation to the point where it handled more than just what 2.0 did - that CBREAK was now supported and ECHOE got left alone. (They didn't add support for TANDEM, but that's pretty obscure.) You can argue that you should not use stty on a System III derivative such as Xenix, but you'll find that lots of pieces shipped with Xenix, like vi and curses, use it. It is possible that Xenix 286 has less support for the V7 tty driver than Xenix 3.0 does; I think I would have noticed if my echoe bit got cleared every time I went into vi or ran a program that uses curses. However, not having the source to Xenix, I can't be sure.