aus 4 chars einen Integer errechnen

Hallo!

Ich schreibe einen Hexeditor und möchte nun verschiedene Daten z.b. über einen ELF-Anwendungsheader ausgeben.

Die Daten liegen mir in einem char-arry vor.
Doch irgendwie schaffe ich es nicht, den Integer-wert aus 4 char-Werten zu errechnen.

fv = data[27];
	fv << 1;
	fv += data[26];
	fv << 1;
	fv += data[25];
	fv << 1;
	fv += data[24];
	printw("[0x0000020] program entry point: %X\n", fv);

hi,

fv << 1;

sollte das nicht 8 statt 1 sein?

CStoll

Erstens hat die Anweisung fv<<1; keinen Nebeneffekt (d.h. sie berechnet nur einen Wert, verwirft ihn aber sofort wieder). Und zweitens schiebt sie fv um jeweils 1 Bit nach links (für deine Codierung brauchst du vermutlich 1 Byte=8 Bit).

Also die Lösung: Ersetze diese Anweisungen jeweils durch fv<<=8; (wenn du portabel bleiben willst: fv<<=CHAR_BITS; ).

Danke, CStoll, das war schonmal gut.

Doch der Programm-entry-point kann nicht stimmen.

//eben vergessen:
int fv = 0;
char *data;
//[...]

	fv = data[27];
	fv <<= 8;
	fv += data[26];
	fv <<= 8;
	fv += data[25];
	fv <<= 8;
	fv += data[24];
	printw("[0x0000018] program entry point: %X\n", fv);

Er sagt mir "[0x0000018] program entry point: 8048BB4"
Im Hexeditor steht auch "B4 8B 04 08"

Nur ist meine Anwendung nur 7484h Bytes groß...

CStoll

Dafür kann die Datenumwandlung nichts Woher bekommst du denn diese Daten?

(und wo und wie das Betriebssystem deine Anwendung im Speicher verteilt, hängt auch von mehr Faktoren ab als nur deren Größe)

schau mal nach den Stichworten: Big Endian, Little Endian

GCoder

CStoll schrieb:

Dafür kann die Datenumwandlung nichts Woher bekommst du denn diese Daten?

Dazu habe ich eine ppt-Präsentation gefunden.
Ich weiß, an welcher Stelle die Adresse stehen müsste, nur ist sie falsch

Aber vlt. ist das auch nicht so wichtig.
Alle anderen Header-Informationen kann ich ja auslesen...

CStoll

GCoder schrieb:

Dazu habe ich eine ppt-Präsentation gefunden.
Ich weiß, an welcher Stelle die Adresse stehen müsste, nur ist sie falsch

Und wie definierst du diese "falsch"?

Naja, der Program entry piont beschreibt ja die Stelle, an der der Maschinencode in der Datei anfängt.

Wenn jetzt die Position des program entry pionts größer ist, als die Datei groß ist, muss ja irgendetwas schief gelaufen sein, oder?

camper

GCoder|unlogged schrieb:

Naja, der Program entry piont beschreibt ja die Stelle, an der der Maschinencode in der Datei anfängt.

Wenn jetzt die Position des program entry pionts größer ist, als die Datei groß ist, muss ja irgendetwas schief gelaufen sein, oder?

Keinesfalls. Zum Einen muss der in einer Datei enthaltene Code nicht unmittelbar ausführbar sein (und ist es oft auch nicht). Zum Anderen ist desen Lage in der Datei auch völlig unwichtig. Wann wird dann denn der Einsprungpunkt interessant? Erst dann wenn, das Betriebssystem das Programm tatsächlich startet, also nach dem Laden. Richtigerweise beschreibt die in der Datei angegebene Einsprungadresse die tatsächliche Adresse des Einsprungs nach dem Laden (wobei diese möglicherweise noch durch den Loader modifiziert wurde). Diese Adresse hat in der Regel hat nichts mit der Lage des Codes in der Datei zu tun. Die Datei selbst ist ja kein exaktes Abbild des Programms, so wie es später ausgeführt wird.

tntnet

fv += data[26]

rechnet vorzeichenbehaftet. Wenn data[26] also im höchstwertigen Bit eine 1 hat, ist er negativ. Besser wäre:

fv |= data[26]

bei den anderen natürlich auch.

Tntnet

camper schrieb:

[Keinesfalls. Zum Einen muss der in einer Datei enthaltene Code nicht unmittelbar ausführbar sein (und ist es oft auch nicht). Zum Anderen ist desen Lage in der Datei auch völlig unwichtig. Wann wird dann denn der Einsprungpunkt interessant? Erst dann wenn, das Betriebssystem das Programm tatsächlich startet, also nach dem Laden. Richtigerweise beschreibt die in der Datei angegebene Einsprungadresse die tatsächliche Adresse des Einsprungs nach dem Laden (wobei diese möglicherweise noch durch den Loader modifiziert wurde). Diese Adresse hat in der Regel hat nichts mit der Lage des Codes in der Datei zu tun. Die Datei selbst ist ja kein exaktes Abbild des Programms, so wie es später ausgeführt wird.

Danke.

Denn ich muss feststellen, das Prinzip funktioniert bei .bmp und .wav - Dateien prima. (Bei wosit schnell das Format rausgesucht xD)

Also stimmt jetzt alles, THX@all

tntnet schrieb:

fv += data[26]
hat, ist er negativ. Besser wäre:
fv |= data[26]

Danke!

camper

tntnet schrieb:

Wenn data[26] also im höchstwertigen Bit eine 1 hat, ist er negativ.

Kann. Sich darauf zu verlassen kann auch unangenehme Konsequenzen haben. Im übrigen hilft das Wechseln zu | dann auch nicht. Denn das Problem liegt in der integralen Promotion, und die findet in jedem Falle statt. Tatsächlich ist also ein cast in unsigned char notwendig, um der Problematik sicher zu entgehen. Allerdings predige ich sowieso, im allgemeinen mit vorzeichenlosen Typen zu arbeiten, es sei denn, negative Werte als solche haben eine Bedeutung. ALso

fv |= static_cast<unsigned char>(data[26]);

besser aber

//eben vergessen:
unsigned char *data;
//[...]

unsigned fv = data[24]|(data[25]<<CHAR_BIT|(data[26]<<CHAR_BIT|(data[27]<<CHAR_BIT)));

Simon2

- egal -

was ist mit reinterpret_cast?

//eben vergessen:
unsigned char *data;
//[...]

unsigned int fv = reinterpret_cast<unsigned int>(data + 24);