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