Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!ctrsol!srcsip!tcnet!rosevax!cimcor!mike
From: mike@cimcor.mn.org (Michael Grenier)
Newsgroups: comp.sources.d
Subject: Re: nn and 80286 processors
Message-ID: <804@cimcor.mn.org>
Date: 8 Jul 89 01:08:36 GMT
References: <1415@garcon.cso.uiuc.edu>
Organization: Grenier & friends, Forest Lake, MN
Lines: 40

From article <1415@garcon.cso.uiuc.edu>, by mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel):
> In article <803@cimcor.mn.org> mike@cimcor.mn.org (Michael Grenier)
> writes (more or less):
>> Changed arguments in call to setupterm to NULL,1,NULL from 0,1,0 in
>> term.c since the first and third parameters are supposed to be
>> pointers. 
> 
> 0,1,0 is indeed incorrect; the compiler has to know that the 0s are
> pointers and not just ints (since null pointers are permitted to have
> a size and/or internal representation different than an int 0).
> 

No, (0,1,0) is NOT correct. Because we live in the segmented world of
Intel were character pointers take 4 bytes in large model but integers
take only two. 

Basically setupterm is defined as follows :

setupterm(term, filenum, errret)
char *term;
int filenum;	/* This is a UNIX file descriptor, not a stdio ptr. */
int *errret;

Passing 0,1,0 will really screw up the stack by pushing only 2 bytes
for the errret parameter resulting in a core dump (if you're lucky :-)

Fortuantely, NULL is usually defined the size of a pointer on the
machine. In large model, Microport correctly defines NULL as 0L. I believe
this is also done in the MSDOS world for many compilers. Of course, you
could make the call to tgetstr as
    tgetstr( (char *) 0, 1, (int *) 0);

But I was too lazy...

Passing 0 is the same as passing an integer..the compiler does NOT need to
know that a 0 is a pointer. ANSI, given a decent function prototype for
tgetstr, will do the cast for you...but not with these older K&R compilers.

    -Mike Grenier   
    mike@cimcor.mn.org