switch case auf union und struct gehen schief

versuch mal

1

...

2

  unsigned char ek : 2;  //Elektrodenkontrolle

3

...

natürlich bei allen variablen.

Volker

Jdelphi schrieb:
> Der post oben drüber bezieht sich darauf, dass ich i_help den wert von
> reg0.ek zuweise. Danach dürfte i 0x00, 0x01, xFF oder 0xFE haben.

Besser (anschaulicher) :
-2,-1,0 und 1.

Jdelphi schrieb:
> Ich hatte auch bisher immer gedacht das ein Char kein vorzeichen hatt.

Das ist in C nicht festgelegt und wird der jeweiligen Implementierung 
überlassen.

Darum ist es zb extrem wichtig, dass man sich die Sichtweisen aneignet:

   char            für Textverarbeitung

   signed char     für alle Berechnungen mit kleinen Zahlen
                   mit Vorzeichen

   unsigned char   für alle Berechnungen mit kleinen Zahlen
                   ohne Vorzeichen

Am besten fährt man, wenn man es sich zur Gewohnheit macht, zwischen 
diesen 3(!) Datentypen streng zu unterscheiden. char ist ausschliesslich 
für Zeichenverarbeitung reserviert und wenn man mit Bytes operiert, dann 
ist unsigned char der richtige Datentyp. Alles andere führt über kurz 
oder lang immer irgendwann zu Problemen. Und sei es nur bei 
automatischen Datetyperweiterungen (Integer Promotions), wenn ein char 
laut Standard-C-Regeln zu einem int aufgeblasen werden muss.

Karl Heinz Buchegger schrieb:
> Am besten fährt man, wenn man es sich zur Gewohnheit macht, zwischen
> diesen 3(!) Datentypen streng zu unterscheiden.

Blöd ist nur, wenn man Protokolle hat, die Text und Daten enthalten (was 
in der Regel der Fall ist).
Bei unsigned char meckert der GCC, wenn man es als Text parst.
Bei char wird nicht gemeckert, aber dann geht das Daten auslesen schief, 
da char nach signed int expandiert.

Wie kann man nur auf die blöde Idee kommen, daß es negativen Text gibt.

Die C-Entwickler haben einem damit ein ganz schönes Ei ins Nest gelegt, 
das jeder Programmierer ausbaden muß und sich dumm und dämlich castet.

Ich bin darauf auch schon reingefallen.

Am saubersten wäre es, Datenströme immer als unsigned zu definieren und 
dem GCC das Meckern darüber abschalten zu können.


Peter

Peter Dannegger schrieb:

> Wie kann man nur auf die blöde Idee kommen, daß es negativen Text gibt.

Anno 1970 gab es nur positiven Text, weil der ASCII-Zeichensatz nur die 
Werte 0-127 kennt. Umlaute hatten die Amerikaner nicht auf der Rechnung.

> Die C-Entwickler haben einem damit ein ganz schönes Ei ins Nest gelegt

Genau genommen waren es nicht die C-Entwickler, sondern DEC.

Damals brachte DEC die PDP-11 raus, deren Bytebefehle die Daten vor der 
Rechnung vorzeichenbehaftet nach 16 Bits konvertiert und dann 
verarbeitet. Wem da ein gewisser Zusammenhang mit der Definition von C 
auffällt: Auf solchen Maschinen hat Unix seine Kindheit verbracht, und 
damit auch C. Vorzeichenlos wäre Zeichenverarbeitung weniger effizient 
gewesen.

Und weil viele sich daran gewöhnt hatten, dass "char" vorzeichenbehaftet 
ist, hat man das so fortgesetzt und viele Compiler machen das auch heute 
noch so. Nicht selten umschaltbar.

A. K. schrieb:

>> Die C-Entwickler haben einem damit ein ganz schönes Ei ins Nest gelegt
>
> Genau genommen waren es nicht die C-Entwickler, sondern DEC.
>
> Damals brachte DEC die PDP-11 raus, deren Bytebefehle die Daten vor der
> Rechnung vorzeichenbehaftet nach 16 Bits konvertiert und dann
> verarbeitet. Wem da ein gewisser Zusammenhang mit der Definition von C
> auffällt: Auf solchen Maschinen hat Unix seine Kindheit verbracht, und
> damit auch C. Vorzeichenlos wäre Zeichenverarbeitung weniger effizient
> gewesen.

Interessante Anekdote. Das wusste ich bisher gar nicht. Dank dafür.


Aber Peter hat schon recht. Da ist wohl jeder im Laufe seiner Laufbahn 
ein paar mal reingefallen. Und aus Erfahrung weiß ich: Bei sowas suchst 
du dich dumm und dämlich.

     if( c == 212 )

der Debugger zeigt dir c in hex an, 0xD4 ist 212, und du denkst die 
ganze Zeit: verdammt, das Bitmuster stimmt. Warum schlägt der Vergleich 
nicht an!

DirkB schrieb:

> Wie wird das denn bei IBM mit EBCDIC gelöst?

Bloss weil DEC bei der PDP-11 die Byteverarbeitung so implementierte, 
dass man Reste davon noch heute in C wiederfindet, musste IBM das Jahre 
zuvor ja nicht auch so machen.

Und ja, die IBMs 360/370er wurden nicht mit C behelligt, sondern 
hauptsächlich mit Fortran, Cobol und viel Assembler. Oder PL/I. Die 
Besonderheit an C ist die Einstufung von Einzelzeichen als Zahlenwerte, 
also "char" als kleiner Integer. Das ist in anderen Sprachen 
ungebräuchlich. Ohne dies hat man das Problem nicht.

Peter Dannegger schrieb:
> Blöd ist nur, wenn man Protokolle hat, die Text und Daten enthalten (was
> in der Regel der Fall ist).

Dafür haben die C-Götter den typecast erfunden.

Den muss man bei Texten dann typischerweise zweimal benutzen: jeweils
an der Import- und an der Export-Schnittstelle, also bspw.

1

  char buf[];

2

3

  buf[idx++] = (char)UDR;

4

5

...

6

7

  lcd_sendbyte((uint8_t)*cp++);