aus 4 chars einen Integer errechnen

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