mike@cimcor.mn.org (Michael Grenier) (07/03/89)
For those of you trying to get nn to run on brain-damaged 16 bit
processors (like mine :-) :
Changed parms in call to setupterm to NULL,1,NULL from 0,1,0 in term.c
sinec the first and third parameters are supposed to be pointers.
For UNIX V.2 (in this case Microport) Add declarations for tgoto
in /usr/include/term.h which is used in term.c .i.e :
extern char *tgoto();
Of course, you could add that in all the files that include term.h
At this point, I was still getting core dumps in rc.c which I couldn't
figure out so in a moment of desparation I linked in the malloc library
that was posted to comp.sources.misc awhile back. (m286 - you can get it
from me if you have problems...however, I'm compiling nn using the beta
release of the UNIX V.3 compiler Microport ported for the 80286 which
may also have created the problem). The memory faults went away.
Finally, I ran into the problem described in the PROBLEMS file where
nn wouldn't find any articles to read. Here again an integer was used
where a 32 bit value should have been.
In nn.c , routine read_news(), change the second parameter in the call to
group_menu from -1 to -1L
Good Luck,
-Mike Grenier
mike@cimcor.mn.org
uunet!rosevax!cimcor!mikemcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) (07/05/89)
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). The proposed ANSI C standard permits NULL to be #defined as 0. Many existing sites have this #definition. Therefore, to change 0,1,0 to NULL,1,NULL will often do nothing, and will be as incorrect as before. The correct fix is to cast NULL to the proper argument type, as in (struct foobar *) NULL, 1, (struct stoat *) NULL If it's unclear why this is so, e-mail me and I'll send you some comp.lang.c articles by Chris Torek. -- "Let me control a planet's oxygen supply, and I don't care who makes the laws." - GREAT CTHUHLU'S STARRY WISDOM BAND (via Roger Leroux) __ \ Tim, the Bizarre and Oddly-Dressed Enchanter \ mcdaniel@uicsrd.csrd.uiuc.edu /\ mcdaniel%uicsrd@{uxc.cso.uiuc.edu,uiuc.csnet} _/ \_ {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel
storm@texas.dk (Kim F. Storm) (07/05/89)
In article <1415@garcon.cso.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) writes: >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). I fully agree, but I was fooled by the following wording in the curses manual: "The simplest call would be setupterm(0,1,0) which uses all the defaults", so that is what I did. I have included the various patches for the '286 in patch #4 which is scheduled for friday this week, and have fixed quite a few additional 16/32 bit inconsistencies. I don't have access the a '286 myself, but at least none of the patches can do any harm, and they may even work :-) -- Kim F. Storm storm@texas.dk Tel +45 429 174 00 Texas Instruments, Marielundvej 46E, DK-2730 Herlev, Denmark No news is good news, but nn is better!
mike@cimcor.mn.org (Michael Grenier) (07/08/89)
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
jpr@dasys1.UUCP (Jean-Pierre Radley) (07/11/89)
In article <1415@garcon.cso.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) writes: >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... >0,1,0 is indeed incorrect >Therefore, to change 0,1,0 to NULL,1,NULL will ... be incorrect as before. >The correct fix is to cast NULL to the proper argument type, as in > (struct foobar *) NULL, 1, (struct stoat *) NULL The file already contains a #define NONE, which is NULL cast to a character pointer. So, on my 386 box, I found that I should replace 0,1,0 by NONE,1,NONE -- Jean-Pierre Radley CIS: 72160,1341 jpr@jpradley.UUCP