Why the IAR runtime libraries are built using unsigned plain char ?

First, what are you talking about, (and what do you mean with 'plain'?)

and second, what difference do you expect from the two?

Internally, the processor doesn't make any difference between signed or unsigned. All are just a row of 8 bits.

The C language and its compiler makes a difference, as the compiler generates different processor instructions whcih do different arithmetic jobs, depending on whether a variable is signed or unsigned.

However, I don't understand what this has to do with libraries (or runtime libraries, as these are usually 100% transparent).

The reason of my post is thousands of warning like : Warning[w31]: Modules have been compiled with possibly incompatible settings: Module ?wzt_algorithm uses signed plain chars, while module ?xxmemxfree uses unsigned plain chars

These warring apeared when I added the lib wzt_algorithm which is built using signed char. As I can't rebuild this lib, I would replace the IAR lib in order to clear all these warnings.

This is a really strange warning.

>plain char is (as required by the C standard) signed (if my assumption is correct that 'plain' means 'without singed/unsigned modifier')

Anyway, the module functions should know what type of parameters they use, so it should work. They are already compiled, so the code and what it does to its parameters, is fixed and won't change during link stage.

I never heard of this warning before, so I don't know what to do. Don't you find at least an explanation in your compiler/linker manual?

However, if a module uses a certain type, it cannot be changed to a different type without changing its behavior too, so I doubt you can just recompile the other module with 'compatble' settings. except, of course, the settings are don't care as they do not apply to the code at all. But then the warning is superfluous.

IAR is configurable for the sign of the plain char type.

It sounds like the OP has a third party library 'wzt_algorithm' which was compiled using signed plain chars. The IAR libraries are configured to use the plain char as unsigned.


ftp://ftp.iar.se/WWWfiles/msp430/webic/doc/EW430_CompilerReference.pdf
Page 187:

--char_is_signed
Syntax --char_is_signed
Description By default, the compiler interprets the plain char type as unsigned. Use this option to
make the compiler interpret the plain char type as signed instead. This can be useful
when you, for example, want to maintain compatibility with another compiler.
Note: The runtime library is compiled without the --char_is_signed option and
cannot be used with code that is compiled with this option.
Project>Options>C/C++ Compiler>Language>Plain ‘char’ is

JMG, you are correct that just changing the setting and recompiling is a bad idea. This excerpt from the Compiler manual says that explicitly! ;)


However, I believe that the plain char is actually one of those vague, compiler dependent details of the C language, which is why I never use it unless I have no other choice.

©ISO/IEC ISO/IEC 9899:1999 (E), Page 35

The three types char, signed char, and unsigned char are collectively called the character types. The implementation shall define char to have the same range,
representation, and behavior as either signed char or unsigned char. *35 (<-- Footnote 35)

*35 CHAR_MIN, defined in <limits.h>, will have one of the values 0 or SCHAR_MIN, and this can be
used to distinguish the two options.  Irrespective of the choice made, char is a separate type from the
other two and is not compatible with either.


I guess at this point I have two questions for the OP.

1. Why is your third party library using signed plain chars? What are they used for?

2. Do you care in this instance? It looks like your only conflict is a memfree routine. I wouldn't think it would care about the TYPE of the pointed object as much as the SIZE.

darkwzrd said:

1. Why is your third party library using signed plain chars? What are they used for?

That is a very good question :). I don't know, I acquiered it with a magnetic sensor.

I ask  to the support to build the same library with the default parameter  but they send me again the same lib.

darkwzrd said:

It looks like your only conflict is a memfree routine.

No, I get 1002 warnings like this one. Every routines are concerned.

I asked this question because I don't want to send a project with 1002 warnings to my customer.

Reading your answers, I understand that I have to ask a new third party library built without --char_is_signed param. I hope they will understand my request this time.

Thank you for these explanations.

darkwzrd said:

The three types char, signed char, and unsigned char [...] char is a separate type from the other two and is not compatible with either.

I didn't know that char is different from int. In all environments I used so far a missing 'signed' or 'unsigned' modifier defaulted to 'signed'. For char and int.
I didn't know that plain char is a separate, incompatible type. I wonder why you don't get errors when you assign a plain char to a signed char.

This whol epart of the ISO/IEC doesn't seem to make any sense at all. And only leads to trouble as we can see. What good is a type that can non-portably change its meaning from compiler to compiler or project to project?