Char Array in einzelne Variable

[Paul (Gast)]

Hallo,


ich würde gerne die Werte aus einem char Array alle in eine char 
Variable speichern.

Also:

char test[6] = {9,8,7,6,5,4};
in eine Variable wie wenn ich diese mit char test="987654"; definiere.

Wie stelle ich das am besten an? :)

[Hans (Gast)]

Man kann nicht 6 x 8 = 48 Bit in 8 Bit speichern.

[Max H. (hartl192)]

Hans schrieb:
> Man kann nicht 6 x 8 = 48 Bit in 8 Bit speichern.
Für eine 6-stellige Zahl würden auch 20bit reichen, das sind aber immer 
noch mehr als 8bit.

[Stefan S. (sschultewolter)]

Das geht einfach nicht. Was hast du vor?

[Mark B. (markbrandis)]

Paul schrieb:

> in eine Variable wie wenn ich diese mit char test="987654"; definiere.

Ich nehme mal an, dass die Programmiersprache C ist. Dann müsste es aber 
so lauten:

char *test="987654";

Sonst gibt es nämlich eine "warning: initialization makes integer from 
pointer without a cast". Und womit? Mit Recht!

[Paul (Gast)]

Programmiert wird mit den Arduino-Libarys.

Nun ja es geht darum dass ich mit folgender Libary:
https://github.com/tzikis/ArduinoMD5/ einen MD5-Hash aus einem Array 
erzeugen will. Der Hash lässt sich jedoch nur erzeugen wenn der 
Parameter(zu verschlüsselnde Zahl) mit char definiert sind...

[Max H. (hartl192)]

MD5::make_hash erwartet genau einen String (char*) und den hast du ja 
schon, wozu willst du das Ganze noch in eine einzelne char packen?

[Paul (Gast)]

Ich würde gerne ein ganzes Array hashen welches von einem UDP-Packet 
ausgelesen wird.

[Easylife (Gast)]

char und char* sind 2 dinge.
char ist ein 8-bit wert, char* ist ein pointer (eine Adresse im 
Speicher) ab der mehrere chars zu finden sind (ein String).
Was du offenbar verwenden möchtest ist ein Pointer auf einen String 
(char*).
Und da hat dir Mark Brandis verraten, wie man diesen definiert:
char *test="987654";

"test" enhält dann also die Adresse vom ersten Byte ("9") von "987654".

[Peter II (Gast)]

Paul schrieb:
> Ich würde gerne ein ganzes Array hashen welches von einem UDP-Packet
> ausgelesen wird.

dann mach das doch. Wenn es nicht geht zeigt wie du es machst.

[Stefan F. (Gast)]

Wenn die Daten als Array vorhanden sind, und du die Hash Funktion 
aufrufen sollst, indem du ihr dieses Array übergibst, dann geht das ganz 
einfach so:

unsigned long meineHashFunktion(char* arg) {
   ...
};

char buffer[100];

meineHashFunktion(buffer);

Denn buffer kann wahlweise als array von chars oder als pointer auf 
chars verwendet werden. Die Hash Funktion könnte auch beide Varianten 
als Argument erwarten - letztendlich ist es das Selbe.

Die folgende Code-Fragmente sinnd alle syntaktisch korrekt:

void meineHashFunktion(char* buffer) {
  while (*buffer != 0) {
     char zeichen=*buffer;
     // mach was mit dem zeichen
     buffer++;
  }
}

void meineHashFunktion(char[] buffer) {
  int i=0;
  while (buffer[i] != 0) {
     char zeichen=buffer[i];
     // mach was mit dem zeichen
     i++;
  }
}

void meineHashFunktion(char[] buffer) {
  while (*buffer != 0) {
     char zeichen=*buffer;
     // mach was mit dem zeichen
     buffer++;
  }
}

void meineHashFunktion(char* buffer) {
  int i=0;
  while (buffer[i] != 0) {
     char zeichen=buffer[i];
     // mach was mit dem zeichen
     i++;
  }
}

Wobei die unteren beiden Beispiele natürlich nicht sehr elegant sind.

Die Array Syntax (zeichen=buffer[i]) hat in der Wiederholschleife einen 
Vorteil: Sie weiß wie groß die Elemente des Arrays sind und verrechnet 
den Zeiger korrekt mit dem Index.

Die Pointer Syntax (buffer++) geht stillschweigend davon aus, dass ein 
char ein byte groß ist und dass der Zeiger beim Incrementieren auf das 
nächste Byte Zeigt. Das sind gleich zwei Annahmen, die bei 
ungewöhnlicher Hardwarearchitektur nicht zutreffen könnten.

Es könnte z.B. sein, dass der Speicher 32 Bit breit ist. Dann ergeben 
sich mehrere Möglichkeiten:

a) Eine Speicherzelle kann 4 Zeichen speichern. Wenn das so genutzt 
wird, dann würde das Incrementieren des Zeigers nicht zum nächsten 
zeichen führen, sondern drei zeichen überspringen.

b) Man könnte aber auch einfach nur 8 von den 32 Bit nutzen, dann klappt 
das Incrementieren wieder.

c) Oder der Pointer zeigt beim Incrementieren gar nicht auf die nächste 
Reihe von 32 Bits, sondern bleibt in der gleichen Reihe und zeigt an, 
dass nun das zweite Bytes der Reihe gemeint ist. (Ich glaub' so läuft 
das auf PC's).

d) Und was, wenn ein char gar nicht 8 bit Groß ist? Chinesen könnten 16 
bit bevorzugen, selbst auf einem 8 bit Mikrocontroller. Dann müsste man 
den Pointer doppelt incrementieren.

Da stellt sich mir die Frage, wie eigentlich mein Laptop Zeichen 
speichert. Viele Bits hat ein zeichen wirklich im Speicher, und hängt 
das vielleicht sogar von der Programmiersprache ab?

Fragen über Fragen. Besser nutzt man die Array Syntax (zumindest 
innerhalb der Widerholschleifen), um Zeichenketten abzuarbeiten.

[Thomas K. (thomas_k39)]

Stefan us schrieb:
> Die Pointer Syntax (buffer++) geht stillschweigend davon aus, dass ein
> char ein byte groß ist und dass der Zeiger beim Incrementieren auf das
> nächste Byte Zeigt. Das sind gleich zwei Annahmen, die bei
> ungewöhnlicher Hardwarearchitektur nicht zutreffen könnten.

So ein quatsch!

Auch in der Pointersyntax weiss der Compiler, wie gross ein char ist und 
ändert den Zeiger so dass er auf das nächste char zeigt.

[Max H. (hartl192)]

Stefan us schrieb:
> Viele Bits hat ein zeichen wirklich im Speicher
Das lässt sich ganz leicht herausfinden:

printf("%d bits", 8 * sizeof(char));

Stefan us schrieb:
> Die Pointer Syntax (buffer++) geht stillschweigend davon aus, dass ein
> char ein byte groß ist
Komisch, bei double, int, stuct,... Arrays funktioniert das auch, sind 
die alle 8 bit groß?

[Dirk B. (dirkb2)]

sizeof(char) ist per Definition 1

Allerdings sind 8 Bit nur die Mindestgröße für ein char.
Wie groß ein char ist, kann man mit dem Makro CHAR_BIT feststellen.

printf("%d bits", CHAR_BIT);

[Cyblord -. (cyblord)]

Daher nutzt man Datentypen wie uint8_t um wirklich die Bitanzahl zu 
bekommen die man möchte.

[Udo S. (urschmitt)]

Oh mein Gott!
LERN GRUNDLAGEN!
Mit UDP und MD5 rumspielen aber noch nicht mal die Grundlagen von 
Datentypen und Zuweisungen der Programmiersprache kennen.

Das ist wie wenn man einem 6 Jährigen, der mit Sandförmchen spielt ein 6 
Familien Haus bauen lassen will.

[Stefan F. (Gast)]

> Auch in der Pointersyntax weiss der Compiler, wie
> gross ein char ist und ändert den Zeiger so dass er
> auf das nächste char zeigt.

Ich weiss, das das bei allen mir bekannten Mikrocontrollern und auch 
beim PC der Fall ist.

Aber ist dieses verhalten auch wirklich standarisiert? Gilt es wirklich 
für jeden denkbaren Computer? Was passiert, wenn ein zeichen kleiner 
ist, als die kleinstmögliche Schrittweite der Pointer-Erhöhung (z.B. 
wenn das zeichen 8bit ist, die Speicherzellen jedoch 16bit)?

[Cyblord -. (cyblord)]

Stefan us schrieb:
>> Auch in der Pointersyntax weiss der Compiler, wie
>> gross ein char ist und ändert den Zeiger so dass er
>> auf das nächste char zeigt.
>
> Ich weiss, das das bei allen mir bekannten Mikrocontrollern und auch
> beim PC der Fall ist.
>
> Aber ist dieses verhalten auch wirklich standarisiert?

Das sollte im C Standard so drin stehen.

Ein größerer Schritt als nötig sollte nichts ausmachen, das merkt man 
nicht. Das verschwendet lediglich Speicher.

[Karl H. (kbuchegg)]

Stefan us schrieb:

> Aber ist dieses verhalten auch wirklich standarisiert?

Ist es.

> für jeden denkbaren Computer? Was passiert, wenn ein zeichen kleiner
> ist,

wäre denkbar.
Nichts desto trotz muss dieses Zeichen ja im Speicher gespeichert werden 
können. Und dieser Speicher wird ja irgendwie ja adressiert.

> als die kleinstmögliche Schrittweite der Pointer-Erhöhung (z.B.
> wenn das zeichen 8bit ist, die Speicherzellen jedoch 16bit)?

Dann muss sich der Compiler was einfallen lassen, wie er dieses Problem 
löst. Zum Beispiel indem er 16 Bit für ein char verschwendet. Zum 
Beispiel indem er 2 Zeichen in jede 16 Bit Speicherzelle packt und 
programmintern mit einer 8 Bit Adressierung rechnet, jeweils ein 16 Bit 
Wort aus dem Speicher holt und die nicht relevanten 8 Bits ausmaskiert 
und den Rest geeignet zurechtschiebt.
Insbesondere letzteres muss ein Compiler sowieso können, der Code für 
eine Architektur produziert, bei der es Alignment-Restriktionen gibt von 
denen der Compilerbauer das Gefühl hat, dass er seinem Programmierer 
auch eine Möglichkeit anbieten will, sich davon zu befreien.

[Freddie (Gast)]

Stefan us schrieb:
> Die Pointer Syntax (buffer++) geht stillschweigend davon aus, dass ein
> char ein byte groß ist und dass der Zeiger beim Incrementieren auf das
> nächste Byte Zeigt. Das sind gleich zwei Annahmen, die bei
> ungewöhnlicher Hardwarearchitektur nicht zutreffen könnten.

Blödsinn. C setzt char mit Byte gleich. Es kann in C kein char geben, 
der nicht ein Byte groß ist. Definitionsgemäß.

[PittyJ (Gast)]

Freddie schrieb:
> Stefan us schrieb:
>> Die Pointer Syntax (buffer++) geht stillschweigend davon aus, dass ein
>> char ein byte groß ist und dass der Zeiger beim Incrementieren auf das
>> nächste Byte Zeigt. Das sind gleich zwei Annahmen, die bei
>> ungewöhnlicher Hardwarearchitektur nicht zutreffen könnten.
>
> Blödsinn. C setzt char mit Byte gleich. Es kann in C kein char geben,
> der nicht ein Byte groß ist. Definitionsgemäß.

Das ist Blödsinn. Ich hatte Prozessoren, da hatte jede Speicherzelle 16 
Bit. Ein char hatte auch 16 Bit. Byteweise Adressierung gibt es da 
nicht. Alles 16 Bit.

Schau die mal die TI 28xx Serie an. Wird hier öfter im DSP-Forum 
benutzt.

[Karl H. (kbuchegg)]

PittyJ schrieb:
> Freddie schrieb:
>> Stefan us schrieb:
>>> Die Pointer Syntax (buffer++) geht stillschweigend davon aus, dass ein
>>> char ein byte groß ist und dass der Zeiger beim Incrementieren auf das
>>> nächste Byte Zeigt. Das sind gleich zwei Annahmen, die bei
>>> ungewöhnlicher Hardwarearchitektur nicht zutreffen könnten.
>>
>> Blödsinn. C setzt char mit Byte gleich. Es kann in C kein char geben,
>> der nicht ein Byte groß ist. Definitionsgemäß.
>
> Das ist Blödsinn. Ich hatte Prozessoren, da hatte jede Speicherzelle 16
> Bit. Ein char hatte auch 16 Bit. Byteweise Adressierung gibt es da
> nicht. Alles 16 Bit.

Vorsicht.
Das was C unter einem Byte versteht ist nicht dasselbe was gemeinhin 
unter einem Byte verstanden wird.
In C ist ein 'Byte' einfach nur die kleinste Einheit. Damit ist nicht 
gesagt, dass 1 Byte aus 8 Bit bestehen muss.

[Karl H. (kbuchegg)]

http://stackoverflow.com/questions/881894/is-char-guaranteed-to-be-exactly-8-bit-long

[Paul (Gast)]

Okey danke für eure Antworten, allerdings reichte es die vergessene Null 
Termination für das char Array zu ergänzen.


Nun hat sich schon das nächste Problem angekündigt:

  #include <SPI.h>        
  #include <Ethernet.h>
  #include <EthernetUdp.h>
  #include <MD5.h>

  
  
  //Variablen definieren:
  
  int udppacket;
  int packetbytes=0;
  byte zahlhalter=0;

    
  byte zaehler=0;
  unsigned long clienttime=0;
  

  //Verbindungseinstellungen
  
  //Server
  byte servermac[] = { 0xDE, 0xAD, 0xCE, 0xEF, 0xFE, 0xEA }; //Generierte MAC-Adresse
  IPAddress serverip(192, 168, 3, 1); //IP-Adresse
  IPAddress serversubnet(255, 255, 255, 0); //Subnetzmaske
  unsigned int serverport = 8001;      //Serverport: Für alle weiteren Clientports gilt 800*


//Clients

  IPAddress clientip(192, 168, 3, 2); //ClientIP
  IPAddress clientsubnet(255, 255, 255, 0); //Subnetzmaske
  unsigned int clientport=8002; //Clientport


  char packetbuffer[UDP_TX_PACKET_MAX_SIZE]; //Bufferspeicher um Empfangene Pakete bis zur Bearbeitung zu speichern.
  EthernetUDP Udp; //Beginnt eine UDP-Instanz


  void setup() {
  
  //Starte Ethernet & UDP Libary
  Ethernet.begin(servermac,serverip,serversubnet);
  Udp.begin(serverport);
  Serial.begin(9600);
}


  void loop() {
  
  
  int udppacket = Udp.parsePacket();
  if(udppacket){
  Serial.println(udppacket);
  char zeitarray[udppacket+1]; //Die empfangenen Bytes werden in ein Array geschrieben, und dieses wird um 1 erhöht für die Null Terination.
  Serial.println(udppacket+1);


    
   Udp.read(packetbuffer,UDP_TX_PACKET_MAX_SIZE);
   Serial.println(packetbuffer);
   
   for(int i=0; i<udppacket; i++) {
     
     zeitarray[i]=packetbuffer[i];
     Serial.print("Empfangene Zeit:");
     Serial.println(packetbuffer[i]);
     zaehler++;
  }

   
   if(zaehler==udppacket){
     
     
     //generate the MD5 hash for our string
    unsigned char* hash=MD5::make_hash(zeitarray);
    //generate the digest (hex encoding) of our hash
    char *md5str = MD5::make_digest(hash, 16);
    free(hash);
    Serial.println(md5str);
  //Give the Memory back to the System if you run the md5 Hash generation in a loop
    free(md5str);
    Serial.println(md5str);
    zaehler=0; 
   }  
  }
}

Das empfangen etc. funktioniert problemlos es werden auch 
unterschiedliche Hashes generiert jedoch sind diese falsch.


Ich nehme an es liegt an dieser Zeile:

 char zeitarray[udppacket+1]; //Die empfangenen Bytes werden in ein Array geschrieben, und dieses wird um 1 erhöht für die Null Terination.

Hier wird das array definiert und als größe die empfangene Byteanzahl 
genommen, dann wird diese um 1 addiert um das Array zu 
terminieren..Stimmt daran etwas nicht?

[Stefan F. (Gast)]

An das Array wird ein Byte angehangen, um es zu terminieren. Das 
funktioniert nur, wenn in den Nutzdaten kein NULL Zeichen vorkommt. 
Außerdem darf die Hash Funktion dieses abschließende Zeichen natürlich 
nicht mit verrechnen.

Ich fürchte, dass deine Nutzdaten ein Byte mit dem Wert 0 enthalten.

[Paul (Gast)]

Ja, das stimmt in den übertragenen Daten (Millis-Zeit des Clients) 
kommen 0en vor. Was kann man dagegen tun?

[Paul (Gast)]

Ich habe das gerade ausgetestet,in diesem Array ist keine 0 und es 
funktioniert trotzdem nicht.

 
  #include <SPI.h>        
  #include <Ethernet.h>
  #include <EthernetUdp.h>
  #include <MD5.h>

   char zeitarray[6]={'1','2','3','4','5','6'}; 
   int test=6;

void setup() {
  
  Serial.begin(9600);
  char zeitarray[test+1];


  //generate the MD5 hash for our string
  unsigned char* hash=MD5::make_hash(zeitarray);
  //generate the digest (hex encoding) of our hash
  char *md5str = MD5::make_digest(hash, 16);
  free(hash);
  //print it on our serial monitor
  Serial.println(md5str);
  //Give the Memory back to the System if you run the md5 Hash generation in a loop
  free(md5str);
  Serial.println(md5str);
  
  
  
}

void loop() {
 
}

[Max H. (hartl192)]

Paul schrieb:
> in diesem Array ist keine 0 und es
> funktioniert trotzdem nicht.
Vllt. weil in dem Array gar nichts ist, bzw. nur das was davor in den 
Speicherzellen stand steht. Wenn du eine globale Variable innerhalb 
einer Funktion noch mal deklarierst, wird diese neu auf dem Stack 
angelegt und die globale ist in der Funktion nicht sichtbar.

[Walter S. (avatar)]

Paul schrieb:
> char zeitarray[test+1];

und dass lässt sich compilieren??
Wenn Du den dem Hinweis von Max beachtest wird danach der nächste Fehler 
auftauchen:
du vorher erwähnt hast dass der String null-terminiert sein muss, es 
jetzt aber nicht ist

Tipp: Grundlagen lernen

["Paul" (Gast)]

Walter S. schrieb:
> Tipp: Grundlagen lernen
Spinnst du? Ich habe mit den Noobduino gekauft weil ich das nicht will.

[Karl H. (kbuchegg)]

Paul schrieb:
> Ich habe das gerade ausgetestet,in diesem Array ist keine 0 und es
> funktioniert trotzdem nicht.
>

Das hier

>    char zeitarray[6]={'1','2','3','4','5','6'};

ist ja wieder nicht 0-terminiert!

Sorry, wenn ich das so sage. Aber wenn diese Funktion hier

>   unsigned char* hash=MD5::make_hash(zeitarray);

einen String haben will, dann musst du ihr auch einen String geben. Wenn 
in deinen zu verhashenden Daten ein Byte mit dem binären Wert 0 
vorkommen kann, dann hast du eben keinen C-String mehr und du kannst 
diese Funktion nicht benutzen. So einfach ist das.

Die Leute haben schon recht damit, wenn sie sagen, dass es ohne 
Grundlagen einfach nicht geht. Ein C-String hat genau definierte und 
bestimmte Eigenschaften. Kannst du die nicht erfüllen, dann hast du 
keinen C-String und kannst auch keine Funktionen benutzen, die von einem 
C-String ausgehen.

[Paul (Gast)]

Ok, ich habe mich mal eingelesen und übe die Grundlagen.

Ein char-Dateityp ist also (meist?) mit 1 Byte Speichergröße definiert 
und hat einen Wertebereich von -128 bis 127 (also insgesamt 255 wie 
byte) und kann einen Buchstaben oder Zahlen von -128 bis 127 speichern.

Ein String ist entweder eine eigener Dateityp oder eine Zeichenkette in 
einem Dateityp z.B. in einem char?


Kann man einem char Array einfach eine Zahl mitgeben? Also:

char test[1]
test[0]=1;

Das Array test wurde mit der Größe zwei erstellt (0,1) wenn ich nur 0 
befülle ist dieses Null-Terminiert.

Liege ich richtig?

[Peter II (Gast)]

Paul schrieb:
> Liege ich richtig?

nein. Ein char[1] ist nur ein Array mit einem element.

> Ein char-Dateityp ist also (meist?) mit 1 Byte Speichergröße definiert
> und hat einen Wertebereich von -128 bis 127 (also insgesamt 255 wie
> byte) und kann einen Buchstaben oder Zahlen von -128 bis 127 speichern.

nein. ein char kann je Einstellung vom Compiler 0-255 oder -128 - 127 
gehen.

[Paul (Gast)]

Ich dachte Arrays sid generell zero-indexed, liege ich da falsch?
Achso ok, danke.

[Paul (Gast)]

Ah ok, Fehler bemerkt auch wenn das Array[1] ist, beginnt dieses bei 0.

[Joachim B. (jar)]

Peter II schrieb:
> nein. ein char kann je Einstellung vom Compiler 0-255 oder -128 - 127
> gehen.

eben und das verstehe ich immer noch nicht weil -char keinen Sinn 
ergibt, manche Compiler auf unsigned char bestehen was aber Unsinn ist, 
besser verständlich finde ich uint8_ und int8_t und was ist mit dem 
ASCII Code der nur 7-bit kennt

Paul schrieb:
> Ah ok, Fehler bemerkt auch wenn das Array[1] ist, beginnt dieses bei 0.

stimmt doch eine Var im Array Länge 1 Index 0

[Peter II (Gast)]

Joachim B. schrieb:
> eben und das verstehe ich immer noch nicht weil -char keinen Sinn
> ergibt, manche Compiler auf unsigned char bestehen was aber Unsinn ist,
> besser verständlich finde ich uint8_ und int8_t und was ist mit dem
> ASCII Code der nur 7-bit kennt

es spielt doch keine rolle welche zahlen man ein char speichern kann.

char ist für Buchstaben.

char c = 'x'

ob es nun unsigned oder signed ist spielt dafür kein rolle.

Wenn man zahlen braucht, nimmt man kein char.

[Max H. (hartl192)]

Peter II schrieb:
> Wenn man zahlen braucht, nimmt man kein char.
Wieso nicht? Ich verwende immer char wenn wenn ich nur kleine Zahlen 
brauche.

[Peter II (Gast)]

Max H. schrieb:
>> Wenn man zahlen braucht, nimmt man kein char.
> Wieso nicht? Ich verwende immer char wenn wenn ich nur kleine Zahlen
> brauche.

wenn die Zahlen < 128 sind ist es ja ok. Wenn du bis 256 brauchst dann 
ist char falsch denn es ist nicht festgelegt ob es signed oder unsigned 
ist.

[Joachim B. (jar)]

Peter II schrieb:
> ob es nun unsigned oder signed ist spielt dafür kein rolle.
>
> Wenn man zahlen braucht, nimmt man kein char.

wo steht das denn?

warum soll ich für Zahlen im Bereich 0-255 ein int oder uint 
reservieren, unter der Voraussetzung das die meisten int/uint als 16 Bit 
betrachten.

Beim MC oder PC ist das sowas von Speicherplatzverschwendung.
Nun kommt mir nicht mit Speicher ist egal, warum müssen denn die PC 
immer jedes Jahr um GHz oder Core wachsen wenn wir heute immer noch 
dieselben Briefe schreiben oder eine simple Tablle bearbeiten wie anno 
1990.

Wir sind doch mit dem üppigen Umgang von Speicher selbst Schuld wenn wir 
alle Nase lang neue Platten brauchen und uns DSL768 nicht mehr schnell 
genug ist, bzw. uns klicki bunti Browser mit animierter Werbung 
volllabern wo wir eigentlich nur im forum lesen wollen, OK ab und an mal 
ein Bild dazu aber was machen wir? ohne Denken mal eben 12MB aus dem 
Handy einstellen mit Informationsgehalt vom analog TV 320*240 Pix

[Peter II (Gast)]

Joachim B. schrieb:
> wo steht das denn?
>
> warum soll ich für Zahlen im Bereich 0-255 ein int oder uint
> reservieren, unter der Voraussetzung das die meisten int/uint als 16 Bit
> betrachten.

wer sagt das?

für zahlen nimmt man

unsigend char

oder

signed char


für Text nimmt man

char

[Dirk B. (dirkb2)]

Peter II schrieb:
> nein. ein char kann je Einstellung vom Compiler 0-255 oder -128 - 127
> gehen.

Der Standard verlangt mindestens  0-255 für unsigned char und -127 bis 
127
für signed char.

Es darf auch mehr sein. Auch mehr an Bits.

[Peter II (Gast)]

Dirk B. schrieb:
> Der Standard verlangt mindestens  0-255 für unsigned char und -127 bis
> 127
> für signed char.

richtig, es hat auch niemand was anders behauptet.

Es geht um char und hier weiß man erst mal nicht ob es signed oder 
unsigned ist damit kann man nicht einfach 190 drin speichern.