Hacker News Reader

Comment by avadodin | Hacker News Reader

The right choice would probably be to make it signed because everything is an int in trad C and all other trad types are signed unless explicitly specified as unsigned.

Not that I disagree with making basic types unsigned by default, just not in C.

View on HN

It makes no sense for a character type to be signed. This is why D has:

    char - unsigned 8 bits
    byte - signed 8 bits
    ubyte - unsigned 8 bits

char is used for utf-8, byte and ubyte are signed and unsigned small integers. This seems like small thing, but it makes D code much more readable than C.

That would be the self-consistent choice. But it is debatable that it is the right choice when things like the <ctype.h> functions sometimes fall over, either accidentally or deliberately, if erroneously given a signed char, and sign extension can sometimes accidentally yield an EOF value.

I haven't run across a C compiler that defaults to signed char in a looong time. It's time to discard signed char so people can write portable V by default. Use signed char if and when it is needed.

I bet a lot of existing C code will break if one sets char to signed with a compiler switch.

Anybody reviewing C code and sees just char will have to waste time wondering if the code handles the implementation-defined signed-ness correctly.

And yes, I know about stdint.h, a poor attempt to deal with this problem.

...I guess you don't use any C compilers targeting x86-64 then? Cause on all the main configurations in my testing (gcc+linux, clang+linux, clang+windows, msvc+windows) x86-64 uses signed char. As such more programs probably break with forced unsigned char than signed char.

I checked and you're right. It's been a long time since I've programmed in C. I shall have myself flogged forthwith.

it's one of the ABI differences between x86 and arm. on arm, char is an unsigned char

Ah so Java did the right decision with signed bytes! /s

Reply on news.ycombinator.com