Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!milano!bigtex!james
From: james@bigtex.uucp (James Van Artsdalen)
Newsgroups: comp.unix.xenix
Subject: Re: tgetent core dump on sco xenix
Keywords: tgetent,core dump,sco,xenix,large model
Message-ID: <3291@bigtex.uucp>
Date: 5 Jul 88 05:44:30 GMT
References: <54@libove.UUCP> <701@nod2sco> <3222@bigtex.uucp> <414@vector.UUCP>
Reply-To: james@bigtex.UUCP (James Van Artsdalen)
Distribution: comp
Organization: F.B.N. Software, Austin TX
Lines: 35

IN article <414@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) wrote:
> In article <3222@bigtex.uucp> james@bigtex.uucp wrote:
> }IN article <701@nod2sco>, rosso@sco.COM (Ross Oliver) wrote:
> }>     - Declare your functions' return values.

> }This last statement is incorrect, or rather, evidence of a broken
> }compiler.

> XENIX does the right thing.  You can do (char *) assignments and
> comparisons with zero.

int *i, **p;

i = 0;
if (i != 0)
   printf("Broken compiler\n");

p = &i /* ie, not 0 */
if (p == 0)
   printf("Broken compiler\n");

Nobody is saying that "*i = 0; p = *i" needs to yield "p == 0".  But
the above tests should never fail or generate a warning under any
memory model.  I mean, if a compiler can handle

long l;

l = 0;

surely it can handle the "integer constant 0" business (and if it
doesn't handle either, you don't want it).  I can't remember if uPort
did this right with their 286 unix, but I expect better of SCO.
-- 
James R. Van Artsdalen   ...!ut-sally!utastro!bigtex!james   "Live Free or Die"
Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746