char und int_8t nicht das selbe?

Matthias F. (frank91) 08.02.2015 17:39 #4004146

Lesenswert?

•

Hallo

ich dachte immer char und int_8t wäre das selbe.
Dieses C Programm zeigt mir gerade, dass es wohl nicht so ist^^

Ich habe ein Programm welches über die Serie Schnittstelle Daten an 
meinen Controller sendet. Allerdings scheint dieses Programm Probleme 
mit Sonderzeichen zu haben.
Statt ü sendet es die Zahl 195 anschließend 188.
Statt ü sendet es die Zahl 195 anschließend 159.

Das unten stehende Programm funktioniert so. Es passt diesen Fehler 
entsprechend an.

Schreibe ich allerdings statt
char empfangen =0;
das hier
int_8t empfangen =0;
funktioniert meine Auswertung nicht mehr.
Die Zeichen 195 und 188 bzw 159 werden aber trotzdem in mein Array
empfangspuffer übertragen.

Wie kann das sein?

ISR(USARTC1_RXC_vect)
  char empfangen =0;
  empfangen = USARTC1.DATA;
  if (paket_wird_empfangen ==1)
    if (empfangen == '$') //36Wenn das Schlusszeichen $ empfangen wurde
      paket_empfangen =1;
      paket_wird_empfangen =0;
    else
      if(empfangen!= 195) //Anfangszeichen für Sonderzeichen nicht werten
        //Sonderzeichen anpassen
        if(empfangen ==188) empfangen ='ü';
        if(empfangen ==159) empfangen ='ß';
        empfangspuffer[empfangspuffer_zaehler] = empfangen; 
        empfangspuffer_zaehler++;
  if (empfangen == '#')  //35 =#
    paket_wird_empfangen =1;

Beitrag melden Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Markierten Text zitieren Antwort Antwort mit Zitat

Peter II Gast 08.02.2015 17:43 #4004148

Lesenswert?

•

▲
▼

Matthias Frank schrieb:
> ich dachte immer char und int_8t wäre das selbe.

char != int_8t != uint8_t

wobei man abhängig vom Compiler ist ob ein char singed oder unsigend 
ist. Dazu kommt jetzt noch das Problem mit der Codepage. Ü ist nicht 
überall gleich. Sinnvoll ist es hierfür gleich den passende int wert zu 
verwenden.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Fritz G. (fritzg) 08.02.2015 17:43 #4004149

Lesenswert?

•

▲
▼

Du bekommst deine Umlaute anscheinend als UTF-8, das sind 2 Byte für 
diese Zeichen.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Matthias F. (frank91) 08.02.2015 17:47 #4004153

Lesenswert?

•

▲
▼

> char != int_8t

Aber beim Atmel Studio ist es doch das selbe? Oder auch nicht?

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Peter II Gast 08.02.2015 17:50 #4004158

Lesenswert?

•

▲
▼

Matthias Frank schrieb:
> Aber beim Atmel Studio ist es doch das selbe? Oder auch nicht?

nein char ist immer was anders. ob es signed oder unsigned ist kann man 
im Compiler einstellen.

man sollte sie nicht als gleich ansehen.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Matthias F. (frank91) 08.02.2015 17:50 #4004159

Lesenswert?

•

▲
▼

tatsächlich^^

wenn ich signed char schreibe geht es wieder nicht.

also ist ein char wohl ein uint_8t

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Matthias F. (frank91) 08.02.2015 17:51 #4004162

Lesenswert?

•

▲
▼

> nein char ist immer was anders. ob es signed oder unsigned ist kann man
> im Compiler einstellen.

Achso ok. Wieder was gelernt xD

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Peter II Gast 08.02.2015 17:51 #4004166

Lesenswert?

•

▲
▼

For gcc, the default is signed, but you can modify that with 
-funsigned-char. note: for gcc in Android NDK, the default is unsigned. 
You can also explicitly ask for signed characters with -fsigned-char.

On MSVC, the default is signed but you can modify that with /J.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Johannes M. (johannesm) 08.02.2015 18:01 #4004182

Lesenswert?

•

▲
▼

int8_t hat einen Wertebereich von -128 bis +127 für dein oben genanntes 
Beispiel wäre das schon mal nicht Zielführend. Ich würde die eindeutigen 
Datentypen benutzen, dann hat man die Probleme nicht.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Fritz G. (fritzg) 08.02.2015 18:07 #4004192

Lesenswert?

•

▲
▼

Kann dein Compiler keine Warnungen? Bei mir kommt:

main.c:46:40: error: character too large for enclosing character literal type
        if(empfangen ==188) empfangen ='ü';
main.c:47:40: error: character too large for enclosing character literal type
        if(empfangen ==159) empfangen ='ß';
main.c:43:17: warning: comparison of constant 195 with expression of type 'char' is always true
      [-Wtautological-constant-out-of-range-compare]
    if(empfangen!= 195) //Anfangszeichen für Sonderzeichen nicht werten
       ~~~~~~~~~^  ~~~
main.c:46:22: warning: comparison of constant 188 with expression of type 'char' is always false
      [-Wtautological-constant-out-of-range-compare]
        if(empfangen ==188) empfangen ='ü';
           ~~~~~~~~~ ^ ~~~
main.c:47:22: warning: comparison of constant 159 with expression of type 'char' is always false
      [-Wtautological-constant-out-of-range-compare]
        if(empfangen ==159) empfangen ='ß';


Warnungen sind nicht zum Spaß da.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Peter II Gast 08.02.2015 18:08 #4004195

Lesenswert?

•

▲
▼

Fritz Ganter schrieb:
> Kann dein Compiler keine Warnungen? Bei mir kommt:
> main.c:46:40: error: character too large for enclosing character literal type

kann es sein da du eine utf8 Datei erstellt hast? Diese Meldung sollte 
nicht kommen.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Fritz G. (fritzg) 08.02.2015 18:10 #4004198

Lesenswert?

•

▲
▼

Sorry, nehme alles zurück, der avr-gcc warnt tatsächlich nicht, dass der 
Vergleich immer wahr/falsch ist.

Ich habe gcc aufgerufen, aber gcc ist bei mir gar nicht gcc.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Fritz G. (fritzg) 08.02.2015 18:13 #4004202

Lesenswert?

•

▲
▼

@Peter: ja. Aber eigentlich geht es mir um

main.c:43:17: warning: comparison of constant 195 with expression of type 'char' is always true

was anscheinend auch nicht mit -Wall kommt. Das ist echt nicht gut!

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Fritz G. (fritzg) 08.02.2015 18:16 #4004207

Lesenswert?

•

▲
▼

Ich habe es gefunden:

Schreibe -Wtype-limits in deine Compiler-Flags rein, dann bekommst du 
deswegen eine Warnung. Ist anscheinend nicht in -Wall enthalten.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Axel S. (a-za-z0-9) 08.02.2015 18:17 #4004208

Lesenswert?

•

▲
▼

Matthias Frank schrieb:
> ich dachte immer char und int_8t wäre das selbe.

Kann so sein, muß aber nicht.

Ein Ärgernis (IMHO) bei C ist, daß die Standard-Datentypen so schwammig 
definiert sind:

char - kann ein Zeichen halten
int - Ganzzahl-Typ mit (ca.) der Bitbreite der CPU

Weil man für viele Anwendungen aber Typen mit genau bekannter Bitbreite 
und signedness (ist bei char z.B. unbestimmt) braucht, hat man mit C99 
das System-Headerfile stdint.h [1] eingeführt, das Integertypen mit 
vorhersagbarer Bitbreite und Signedness definiert.

[1] https://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Nase Gast 08.02.2015 18:19 #4004211

Lesenswert?

•

▲
▼

Fritz Ganter schrieb:
> was anscheinend auch nicht mit -Wall kommt. Das ist echt nicht gut!

-Wextra

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Michael R. (fisa) (Firma: Brainit GmbH) 08.02.2015 18:21 #4004213

Lesenswert?

•

▲
▼

Fritz Ganter schrieb:
> Schreibe -Wtype-limits in deine Compiler-Flags rein, dann bekommst du
> deswegen eine Warnung. Ist anscheinend nicht in -Wall enthalten.

Korrekt, -Wall aktiviert das nicht, aber -Wextra. Bei mir sind 
grundsätzlich immer beide aktiv, Code der Warnungen wirft wird nicht 
committed, sprich Warnungen werden immer alle bereinigt.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

char und int_8t nicht das selbe?

Antwort schreiben