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