Newsgroups: comp.unix.sysv386
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!lethe!tvcent!comspec!scocan!larryp
From: larryp@sco.COM (Larry Philps)
Subject: Re: SCO's curses
Organization: SCO Canada, Inc.
Date: Tue, 16 Apr 1991 18:50:25 GMT
Message-ID: <1991Apr16.185025.27706@sco.COM>
References: <1991Mar22.211749.13292@robobar.co.uk> <1991Apr11.022708.11563@sobeco.com> <1991Apr16.010851.6047@NCoast.ORG>
Sender: news@sco.COM (News administration)

In <1991Apr16.010851.6047@NCoast.ORG> allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) writes:

> 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.

There is a compiler option (documented), -J, that will cause the compiler
to change the default type of char from signed to unsigned.  This should
also fix things.

---
Larry Philps,	 SCO Canada, Inc (Formerly: HCR Corporation)
Postman:  130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
InterNet: larryp@sco.COM  or larryp%scocan@uunet.uu.net
UUCP:	 {uunet,utcsri,sco}!scocan!larryp
Phone:	 (416) 922-1937
Fax:	 (416) 922-8397