"itoa" verrückter Wert?

Mipe

Hallo zusammen,

ich habe hier ein ganz seltsames Phänomen, welches mir ganz schön Kopfzerbrechen bereitet.

Mit folgendem Code lese ich ein übergebenes Zeichen ein und will es in einen Binärwert umwandeln:

char* Buffer = new char[8];
itoa(Value[i],Buffer,2);

Sobald in Value[i] der Ascii-Wert 150 steht, steht in Buffer nicht "10010110" sondern "111111111111111111111110010110". Woher kann denn diese Wahnsinnszahl kommen? Liegt es an den Vorzeichen? Bis 127 geht es nämlich noch korrekt? Aber mit (unsigned...) kommt immer dasselbe raus.

Für eine kleine Hilfe wäre ich sehr dankbar,
Mipe

Jansen

Was ist Value[]?

dreaddy

Buffer ist zu klein
wie soll der in 8 chars 8 Zahlen und eine 0 bekommen

[ Dieser Beitrag wurde am 01.07.2003 um 11:56 Uhr von dreaddy editiert. ]

Mipe

Das mit Buffer spielt keine Rolle, da ich vorher bei Buffer[20] dasselbe Ergebnis bekommen habe.

Value[] ist ein Char-Array, bei dem an Stelle [i] eben das Ascii-Zeichen 150 steht (genauer: '–' 150 (0xFFFFFF96))

Wenn ich mir die Hex-Zahl hinter den 150 anschaue, dann kann ich das schon verstehen. Sollte das nicht 0x000..96 sein?

Mipe

[ Dieser Beitrag wurde am 01.07.2003 um 12:09 Uhr von Mipe editiert. ]

flosko

Original erstellt von Mipe:
**
Wenn ich mir die Hex-Zahl hinter den 150 anschaue, dann kann ich das schon verstehen. Sollte das nicht 0x000..96 sein?
**

wie gibst du die zahlen aus?

dreaddy

Dann hast du noch einen char Überlauf.
char hat(wenn man es nicht anders im Compiler einstellt) den Zahlenbereich von
-128 bis 127 ... 150 ist da dann etwas viel.

*edit* ok genaugenommen nicht 0-127

[ Dieser Beitrag wurde am 01.07.2003 um 13:21 Uhr von dreaddy editiert. ]

Knuddlbaer

char: -127 bis 128
unsigned char 0 - 255

?!

Die vielen Zeichen davor kommen vom - .

Versuch mal

unsigned char * Buffer = new unsigned char[8];

[ Dieser Beitrag wurde am 01.07.2003 um 12:48 Uhr von Knuddlbaer editiert. ]

Jansen

Kein BCB-Problem. Verschoben nach "C++".

Mipe

Wenn ich das ganze mit "unsigned char" erstelle, dann wird gar nichts mehr aus der Datei eingelesen. Mein vollständiger Code an dieser Stelle sieht folgendermaßen aus:

// Beim drücken des Buttons werden x Byte aus einer Datei gelesen
// und die Funktion getSize() aufgerufen
void __fastcall TForm1::Button2Click(TObject *Sender)
{
  if (Edit3->Text != "")
  {
    int   iTemp = StrToInt(Edit3->Text);
    unsigned char* pchTemp = new  unsigned char(iTemp);

    ifstream datei;
    datei.open("C:\\test.txt",ios::binary);

    char Buffer;

    for (int i = 0; i < iTemp; i++)
      datei.get(pchTemp[i]);  // hier passiert bei unsigned nichts!!!
                              // Bei signed wird normal eingelesen!!!
    datei.close();

    int Value = getSize(pchTemp,iTemp);
    Edit2->Text = IntToStr(Value);
  }
}

So, wenn ich das ganze also mit unsigned mache, dann liest er gar keine Zeichen aus der Datei ein. Nur mit dem normalen char... woran kann das liegen?

Mipe

junix

Den Prototypen von itoa kennst du oder?

[cpp]char *itoa(int value, char *string, int radix);[/cpp]

Die wichtigen Stellen hab ich mal fett markiert...

-junix

<edit>Ok, das mit dem Fett ging in die Hose, aber schau dir mal an wie value deklariert ist. Wenn ein signed wert erwartet wird, erfolgt bei unsigned werten immer ein impliziter cast nach signed (soviel ich weiss)... klingelts?</edit>

[ Dieser Beitrag wurde am 01.07.2003 um 14:10 Uhr von junix editiert. ]

sieht man aber nix von :p :p :p

Bashar

Value[i] nach unsigned char zu casten sollte es tun.

groovemaster

Value[] ist ein Char-Array

itoa wandelt keine Zeichen, sondern int's um. Dh aus deiner 150 (als char -106 wegen -128..127 Wertebereich) wird ein int -106. Und das hat binär nunmal soviele Stellen.
btw:

Das mit Buffer spielt keine Rolle

Tut es schon, wenn du keinen Buffer Overflow haben willst.

Mipe

Hey, mit

itoa((unsigned char)Value[i],Buffer,2);

haut's wunderbar hin. Danke.

Mipe

PS. Natürlich spielt der Buffer mit Größe 8 eine Rolle, jedoch nicht für das Problem des Chars meinte ich

Ich glaube es weiss nicht jeder, woher der "Fehler" den nun
eigentlich herkommt, deshalb noch eine kurze Erläuterung:

itoa erwartet ein int als Parameter, bekommt aber ein char.
Der Kompiler "denkt": char < int also alles okay.
Bei positiven Werten ist dann auch alles okay; bei negativen Werten
werden die 24 zusätzlichen Bits aber mit 1en aufgefüllt (2er Komplement).

itoa arbeitet also völlig korrekt.

Jockel

&quot;itoa&quot; verrückter Wert?

"itoa" verrückter Wert?