Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!rex!uflorida!gatech!usenet.ins.cwru.edu!ncoast!allbery
From: allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA)
Newsgroups: comp.unix.sysv386
Subject: Re: SCO's curses
Message-ID: <1991Apr16.010851.6047@NCoast.ORG>
Date: 16 Apr 91 01:08:51 GMT
References: <1991Mar22.211749.13292@robobar.co.uk> <1991Apr11.022708.11563@sobeco.com>
Reply-To: allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA)
Followup-To: comp.unix.sysv386
Organization: North Coast Public Access Un*x (ncoast)
Lines: 26

As quoted from <1991Apr11.022708.11563@sobeco.com> by mfp@sobeco.com (m.proudman):
+---------------
| int c;
| addch((chtype)(c&0377));
| 
| and also:
| 
| char * p;
| addch((chtype)((*p)&0377));
| 
| I experienced problems similar to yours, and came up with this after
| a bit of playing.  Perhaps someone can give a complete explanation as
| to why it works.
+---------------

(char) is signed on 386/486 processors.  So, (char) 0200 gets sign-extended to
a (chtype) (actually, a (long)) with all the attribute bits set and probably
some wild color specifications as well.  Either mask against 0377 (or 0xFF,
same thing --- or even 255) or use (unsigned char) types.

++Brandon
-- 
Me: Brandon S. Allbery			  Ham: KB8JRR/AA on 2m, 220, 440, 1200
Internet: allbery@NCoast.ORG		(QRT on HF until local problems fixed)
America OnLine: KB8JRR // Delphi: ALLBERY   AMPR: kb8jrr.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery          KB8JRR @ WA8BXN.OH