Gcc: force compiler to use unsigned char by default

Question

Since the nature of a char in C++ is compiler-dependent when the unsigned qualifier is not present, is there an argument I could pass on to GCC which would force all chars to be compiled as unsigned?

Brittenybrittingham

I found this out in ten seconds by Googling gcc force unsigned char then reading the GCC documentation that comes up. What prevented you from performing this research? – Deflate

@LRO, because you are clearly much quicker than trawling through google... ;) – Eloquence

It's probably better to use unsigned char rather than plain char. Your program will likely be linked with code that was compiled without -funsigned-char. If you depend on unsigned bytes, it's safer to express that in the code rather than in a compiler option. – Jangro

@Keith -- that is the craziest comment I've read here. A plain text ascii file doesn't know if the bytes are signed or unsigned, let alone memory. Some platforms have char as unsigned by default. The char data type specification was written to not be very particular about the signedness to begin with. – Barbecue

@B.Nadolson: You must not have read many comments if you think mine is the craziest. The question wasn't about ASCII text files, it was about the type char. The type char is very particular about its signedness. On some implementations it's particularly signed; on others it's particularly unsigned. If the signedness matters, you should use signed char or unsigned char; that's why they exist. – Jangro

Answer 1

The flag you are looking for is -funsigned-char.

From the documentation:

-funsigned-char

Let the type char be unsigned, like unsigned char.

Each kind of machine has a default for what char should be. It is either like unsigned char by default or like signed char by default.

Ideally, a portable program should always use signed char or unsigned char when it depends on the signedness of an object. But many programs have been written to use plain char and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for. This option, and its inverse, let you make such a program work with the opposite default.

The type char is always a distinct type from each of signed char or unsigned char, even though its behavior is always just like one of those two.

---

-fsigned-char

Let the type char be signed, like signed char.

Note that this is equivalent to -fno-unsigned-char, which is the negative form of -funsigned-char. Likewise, the option -fno-signed-char is equivalent to -funsigned-char.

This only impacts char; types like wchar_t are unaffected.

Deflate

Can you confirm this flag has no impact on the signedness of wchar_t? – Agathaagathe

@Antonio: No idea, sorry. – Deflate

@Antonio: Yes. – Deflate

Answer 2

As the other answers say, gcc's -funsigned-char option forces plain char to be unsigned.

But that may not be the best solution to your problem. You want unsigned characters, but by using a compiler-specific option you're encoding that information in the build command (the Makefile, build script, or just the command you type to compile your code). If the semantics of your program depend on having unsigned characters, it's better to record that information in your source code. It's clearer, and it's reduces the chance that someone will build your program incorrectly.

If you want unsigned characters, using unsigned char. If you want signed characters, use signed char. If you just want characters, and you're sure your program's behavior doesn't depend on whether they're signed or unsigned (say, if all stored values are in the range 0..127), use char.

Jangro

Keith I have a question; I would normally agree with the last paragraph of your answer... except... Many POSIX functions have documented interface that uses char, for example the ones that read files (with characters in them). OK, now suppose I want to use them but I want to process bit representations of read characters, and only bit representation of unsigned char is guaranteed. So in that case, it would seem it would be proper to use -funsigned-char . Do you disagree? – Signboard

@MarkGaleck Yes, I disagree, though I can see your point. Normally lines of text are made up of char values, and if you want to read unsigned char values from a file it's rare for the file to be made up of lines (typically it would be a binary file). But if you really need to do that, you can cast a char* pointer that points to a line of text and cast it to unsigned char*. Remember that -funsigned-char doesn't cause the runtime library to treat plain char as unsigned; it only affects the code you compile with that option. – Jangro

ah yes, I see, thank you, yes, I get "records" from files, that are not lines as such, but are char * pointers and I know how long after that the record is, yes I will cast them to unsigned char* – Signboard

@MarkGaleck How are you getting these "records"? Would fread make more sense? – Jangro

thank you! I did not know about fread :) but well, my records are not of the fixed size, I just know what size to expect at any particular moment, but the sizes vary – Signboard

@MarkGaleck Well, if you know how big the next record is, you can pass that size as a parameter to fread. See also https://mcmap.net/q/112806/-how-does-fread-really-work – Jangro

well yes, but the point of fread really is so that I can ready many records at once. – Signboard

@MarkGaleck The point of fread is to read however many records you want to read. There's nothing wrong with reading one record at a time. What are you using now? – Jangro

I see, sorry, ... I got the gist of fread wrong, it is like read except for FILE *. Well OK, I generally work with file descriptors. Anyway, after talking to you, I went and checked carefully, and found that I can just use mmap all the time. So that solves the problem, I don't really need funsigned-char. But it was good to learn stuff from you. Thank you. – Signboard

Answer 3

Not enough reputation to comment @Keith's answer.

The main reason I see to use -funsigned-char or -fsigned-char is when you want the following code

  printf("%d\n",'\x80');

to display either -128 or 128.

The comment about not relying on specific compilation settings is valid but here it is a bit simplifying reality. The main problem is that C leaves some part of the language to the implementation for efficiency reason, and usually you want to tune that implementation to suit best your application. In my opinion a professional developer should always go through all compiler flags and select the best for his needs. If you rely on some specific settings, your unit tests will of course cover that case, or assert it. If you port an application, you will look into the compilation settings of the original port.

Joyance

What does "TMO" stand for? – Deflate

I see. I'm not familiar with that construction. Doesn't seem grammatical to me, either. What does it mean? – Deflate

After some googling, doing s/to/in/ might be clearer for you. Turns out I was using this for years but is incorrect indeed. Thanks for pointing it out! – Joyance

I had to check to confirm that that would even work, because character constants are of type int, but yes, -funsigned-char or -fsigned-char does affect the value of '\x80'. But if I cared, I'd just cast the constant to signed char or unsigned char rather than using a compiler option. Remember that those options apply only to code compiled with the options; library code will still use the implementation's choice of signedness for plain char. The options are there to cater to existing code that was written with unwarranted assumptions. – Jangro

Answer 4

You can use -funsigned-char for that, or -fsigned-char for signed.

Kokoschka

Answer 5

You can use the option: -funsigned-char.

source

Appomattox