wrote= : >> It is undefined in C whether or not it sign extends or not. Some machines= do it one way, some another. To force the language to one behavior requires= more code on some architectures. >=20 > Ironically for its use as an example, that's another case where Plan 9 C d= efines the effect: char is always signed, unsigned char is the only unsigned= form, on all targets, just like int/unsigned int, short/unsigned short. The= abbreviation "uchar" makes it relatively painless. > It's just a pity that string literals must be char*, not uchar*, and all t= he str* functions take char*. --Apple-Mail-2E2B3B79-B623-47E0-87D2-EC4CF6C436C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I've lived with the old definition so l= ong that I didn't notice Plan 9's definition, which is not a problem on toda= y's architectures because there are two equally efficient instructions to ch= oose from.

Sent from my iPad

On Nov 23, 2015, at 7= :05 AM, Charles Forsyth <cha= rles.forsyth@gmail.com> wrote:

On 23 November 2015 at 11:50, Brantley Coile <brantleycoile@me.com> wrote:
It is undefined in C whether or not it sign e= xtends or not. Some machines do it one way, some another. To force the langu= age to one behavior requires more code on some architectures.

Ironically for its use as an example, that's another case w= here Plan 9 C defines the effect: char is always signed, unsigned char is th= e only unsigned form, on all targets, just like int/unsigned int, short/unsi= gned short. The abbreviation "uchar" makes it relatively painless.
It's just a pity that string literals must be char*, n= ot uchar*, and all the str* functions take char*.

= --Apple-Mail-2E2B3B79-B623-47E0-87D2-EC4CF6C436C2--