Xref: utzoo comp.unix.xenix:2612 comp.sources.d:2403 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!jetson!john From: john@jetson.UUCP (John Owens) Newsgroups: comp.unix.xenix,comp.sources.d Subject: Re: tgetent core dump on sco xenix Keywords: tgetent,core dump,sco,xenix,large model Message-ID: <67@jetson.UUCP> Date: 5 Jul 88 15:56:20 GMT References: <54@libove.UUCP> <701@nod2sco> <3222@bigtex.uucp> Distribution: comp Organization: SMART HOUSE Limited Partnership Lines: 36 In article <3222@bigtex.uucp>, james@bigtex.uucp (James Van Artsdalen) writes: > > - Don't use "0" to mean NULL ( i.e. (char *)0 ). > C requires that the integer constant 0 be assignable to *any* pointer > type. C also requires that any pointer type may be compared with the > integer constant 0. If the Xenix compiler requires that the integer > constant 0 be cast to a pointer type first, it is broken. Correct, as far as it goes. 0 must be *assignable* to any pointer type, and the Xenix C compiler should extend it appropriately. Also, when using ANSI C function prototypes, 0 in an argument should be extented to the size of a pointer. But in non-ANSI C, in a large-data model, when passing a null pointer as an argument to a function expecting a pointer argument, "0" will not do, but "(pointer-type *)0" will. This indicates nothing wrong with the Xenix C compiler.] [For anyone who's still not convinced, make the analogy to floats (doubles, actually). While double f; f = 0; works, and double f; extern double fabs(); f = fabs((double)0); works, double f; extern double fabs(); f = fabs(0); /* expects a double */ will not.] -- John Owens SMART HOUSE Limited Partnership john@jetson.UUCP (old uucp) uunet!jetson!john +1 301 249 6000 (internet) john%jetson.uucp@uunet.uu.net