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);

fv << 1;

sollte das nicht 8 statt 1 sein?

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

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ß...

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

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...

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"?

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

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.

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

[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

fv += data[26]

hat, ist er negativ. Besser wäre:

fv |= data[26]

Danke!

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)));

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

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