Ist unsigned char default?

[Jochen (Gast)]

Huhu,

kurze Frage:
Wenn ich eine Variable als char deffinier ist das dan beim AVR GCC
defaultmäßig eine unsigned char Variable?

also:

unsigned char test = chr test != signed char test ?

Danke schon mal vorab, Jochen

[Rufus T. Firefly (Gast)]

Das sollte in der Compilerdokumentation drinstehen.
Zumindest bei anderen Compilern gibt es dafür auch eine Compileroption,
mit der man das einstellen kann.

[Hans (Gast)]

schau mal in deine makefile...


<<<<<<<snip>>>>>>>>>
 Optional compiler flags.
#  -g:        generate debugging information (for GDB, or for COFF
conversion)
#  -O*:       optimization level
#  -f...:     tuning, see gcc manual and avr-libc documentation
#  -Wall...:  warning level
#  -Wa,...:   tell GCC to pass this to the assembler.
#    -ahlms:  create assembler listing
CFLAGS = -g -O$(OPT) \
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums \
-Wall -Wstrict-prototypes \
-Wa,-adhlns=$(<:.c=.lst) \
<<<<<<<snip>>>>>>>>>

und jetzt ein kleiner blick in die gcc-doku...
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/C-Dialect-Options.html#C%20Dialect%20Options

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

73 de oe6jwf / hans

[Jörg Wunsch (Gast)]

Ich denke, ohne Option ist es ein signed char -- aber s. o., darauf
verlassen sollte man sich ohnehin nicht.

[Rufus T. Firefly (Gast)]

Das tolle an der zitierten gcc-Dokumentation ist, daß die mit keinem
Wort darauf eingeht, wie char nun behandelt wird, wenn keine der
genannten Optionen gesetzt wird; was also mag der _default_-Wert sein?

[Jörg Wunsch (Gast)]

Er ist architekturabhängig.

[Jochen (Gast)]

Okay,

danke. In meinem Makefile ist die Option -funsigned-char gesetzt.

Danke für Eure Hilfe
Jochen

[Rufus T. Firefly (Gast)]

> Er ist architekturabhängig.

Aha. Gibt es Hinweise, die einen darauf schließen lassen könnten,
welche Architektur welche Variante bevorzugt?

Kann man denn den Compiler fragen, was er mag?

  gcc -dumpspecs

erwähnt jedenfalls auf meinem System (gcc 3.4.2 für ARM) nichts
derartiges.

[Jörg Wunsch (Gast)]

Ich wüßte es im Moment nicht, wie man es herausfindet...

[Sven A. (Gast)]

Da diese ganze signed char unsigned char geschichte oft unterschiedlich
gehandhabt wird, habe ich mir angewöhnt die Variabeln bei der
deklaration direkt als unsigned char bzw. signed char zu deklarieren.
Damit bin ich dann immer sicher und weiß um welchen Typen von char es
sich bei meiner Variable x handelt.

[Paul (Gast)]

Nur aus Interesse: Wofür, wenn nicht bei contests, bei denen es auf
Tokenanzahl ankommt, muss man wissen, ob char signed oder unsigned
ist?

Portabel wird so ein Code kaum werden.

[Jochen (Gast)]

naja,

ich lese Z.B. eine DS1631 aus. Der Liefert mir halt jeweil 1 Byte und
je  nach dem ob es klat oder war ist eben + oder - Grad.
Und ich denke schon das es dann sinnvoll ist ein signed char zu
verwenden ;-)

Grüßle Jochen

[Jörg Wunsch (Gast)]

Warum willst du ein signed char verwenden?  Was tust du, wenn dein
Code an eine Architektur gerät, bei der sizeof(char) == 4 ist?  (Sowas
soll's geben, zum Bleistift irgendwelche DSPs, die nur 32-bit Integer
können.)

Du willst stattdessen

#include <stdint.h>

...
int8_t mytempval;

benutzen.  Wenn du dann an eine Architektur gerätst, die keine
8-Bit-Werte unterstützt, gibt's einen Compiler-Fehler.  In allen
anderen Fällen darfst du dich drauf verlassen, dass "mytempval" ein
vorzeichenbehafteter 8-bit-Integerwert ist.

[Jochen (Gast)]

Naja,

man lernt ja nie aus ;-)
Werd ich mir mal anschauen, danke.

Gruß Jochen

[Christian Rötzer (Gast)]

Mit folgender Sequenz kann man natürlich schon rausfinden, ob der char
nun signed oder unsigned ist:

char c = 0xC0;
printf("%d",(int)c);

Wenn als Ergebnis 192 da steht, war's unsigned, bei -64 ist's ein
signed char. Und genau solche Zuweisungen führen natürlich zu
Problemen. Ich kann mich insofern nur obiger Meinung anschließen sowas
explizit anzugeben.