Autor Thema: Struktur auf beliebigen Speicher anwenden  (Gelesen 38933 mal)

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #100 am: 12. February 2009, 12:48 »
char *pch;
size_t i;
...
i = (size_t)pch;

Den richtigen Cast verwenden.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #101 am: 12. February 2009, 12:52 »
char *pch;
size_t i;
...
i = (size_t)pch;

Den richtigen Cast verwenden.
:roll: ich Idiot, thx
In the Future everyone will need OS-64!!!

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #102 am: 17. February 2009, 19:51 »
Du darfst mit dem sehr wohl rechnen, aber es wird nicht das sein was du dir vorstellst. zB:
T *t = 0;
++t;
Unter der Annahme, dass T ein Typ der Größe s ist, ist nach diesem Codestück t = 0 + 1 * s = s, d.h. es wird anstatt ein Byte weiterzugehen einmal s Bytes weitergegangen.

Wenn du wirklich bytes weitergehen möchtest, dann macht man das so:
T *t = 0;
t = (T*)((uintptr_t)t + x)
wobei x die Anzahl der Bytes ist die du weiter möchtest.
So, ich möchte also jetzt einen Zeiger um z.B. 5 Bytes erhöhen. Dann geht es so ja nicht:

u32 *zeiger;
//<- hier wird der Wert von Zeiger festgelegt
zeiger += 5;

Wenn ich das richtig verstanden habe, würde in diesem Fall Zeiger um 5*32 Bit = 5*4 Bytes = 20 Bytes erhöht, oder?

Will ich aber tatsächlich nur um 5 erhöhen müsste ich es so machen?

zeiger = (u32*)((uintptr_t)zeiger + 5);
Nur leider sagt mir mein gcc

Zitat
error: ‘uintptr_t’ undeclared (first use in this function)

Sprich ich muss uintptr_t erst in der types.h eintragen. Nur als welchen Typen?

thx

bitmaster
In the Future everyone will need OS-64!!!

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #103 am: 17. February 2009, 22:27 »
Wenn ich das richtig verstanden habe, würde in diesem Fall Zeiger um 5*32 Bit = 5*4 Bytes = 20 Bytes erhöht, oder?
ja.

Zitat
Sprich ich muss uintptr_t erst in der types.h eintragen. Nur als welchen Typen?
Kommt offensichtlich auf die Architektur an für die du programmierst. Bei 32bit wohl uint32_t und bei 64bit wohl uint64_t.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #104 am: 18. February 2009, 13:10 »
Wenn ich das richtig verstanden habe, würde in diesem Fall Zeiger um 5*32 Bit = 5*4 Bytes = 20 Bytes erhöht, oder?
ja.

Zitat
Sprich ich muss uintptr_t erst in der types.h eintragen. Nur als welchen Typen?
Kommt offensichtlich auf die Architektur an für die du programmierst. Bei 32bit wohl uint32_t und bei 64bit wohl uint64_t.
Ah danke. Ich habe aber gesehen dass uintptr_t nicht in die types.h sondern in die stdint.h kommt. Aber wozu brauche ich dann eine types.h, wenn in der stdint.h schon solche Sachen wie int8_t, uint8_t etc. drin stehen? Und wann sollte ich die aus der types.h und wann die aus der stdint.h nehmen? Bzw. wann sollte ich eigentl. generell diese Typen nehmen? Also sollte ich z.B. bei meiner kprint "char *" oder "u8 *" oder "uint8_t *" verwenden?

So, ich habe jetzt noch ein Problem, was nichts mit Programmierung zu tun hat. Ich habe gerade eine Anwendung mittels ./configure und make all install installiert. Nur habe ich diese in dem falschen Verzeichnis installiert. Also ich habe vergessen der ./configure das --prefix=blabla anzugeben. Gibt es eine möglichkeit die Anwendung wieder zu deinstallieren? Also dass er alles rückgängig macht, was ich seit dem ./configure und dem make all install gemacht habe?

thx

bitmaster
In the Future everyone will need OS-64!!!

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #105 am: 18. February 2009, 17:36 »
Ah danke. Ich habe aber gesehen dass uintptr_t nicht in die types.h sondern in die stdint.h kommt. Aber wozu brauche ich dann eine types.h, wenn in der stdint.h schon solche Sachen wie int8_t, uint8_t etc. drin stehen? Und wann sollte ich die aus der types.h und wann die aus der stdint.h nehmen? Bzw. wann sollte ich eigentl. generell diese Typen nehmen? Also sollte ich z.B. bei meiner kprint "char *" oder "u8 *" oder "uint8_t *" verwenden?
Es gibt Standards die dir sagen in welchen Headern welche (Typ-)Definitionen zu finden sind. Einer dieser Standards ist der C99 Standard (bzw. genauer: ISO/IEC 9899:1999, letzter Draft vor der Standardisierung hier) und ein anderer zu C99 kompatibler Standard wäre beispielsweise die Single UNIX Specification bzw. POSIX (siehe hier).
In diesen Standards wird natürlich auch beschrieben was genau für diese Typen garantiert ist, d.h. im Endeffekt was genau man mit diesen Typen machen darf/kann. Was genau du jetzt aber mit "types.h" meinst weiß ich nicht. Ich kenne nur eine "sys/types.h" (nach SUS bzw. POSIX).

Zu "u8": würde ich garnicht verwenden und auch nicht definieren/unterstützen. Es gibt einen Typ (hier uint8_t) nach dem C99 Standard und dann würde ich immer den Typen des Standards nehmen (erhöht Wiederverwendbarkeit und dient dem Verständnis anderer Programmierer).
ansonsten: char* (könnte evtl. mit oder ohne Vorzeichen sein und muss nicht 8Bit sein, gab teilweise auch Archs mit 1Byte = 7, 9 oder 11 Bit afaik) wenn ich von Zeichenketten rede und uint8_t* wenn es mit wichtig ist, dass es sich um Bytes (mit 8Bit) handelt, welche ich ohne Vorzeichen betrachten möchte.
D.h. der Typ spiegelt für mich persönlich auch die Art wie ich ihn verwende wieder.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #106 am: 18. February 2009, 18:48 »
Ah vielen dank bluecode. Also wenn ich nach dem C99 Standard gehe, dann brauche ich keine types.h sondern verwende die stdint.h (war es glaube ich) und nehme anstatt u8 uint8_t, oder?

Demnach sollte ich meine kprint nicht so

void kprint(char* msg);
sondern lieber so

void kprint(int8_t* msg);
definieren?

thx

bitmaster
In the Future everyone will need OS-64!!!

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #107 am: 18. February 2009, 19:40 »
Logisch gesehen gibst du nicht einen Integer aus, sondern Zeichen. Das spräche sehr für char*.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #108 am: 19. February 2009, 08:23 »
Ich wäre ja sehr für ein const dazwischen:
void kprint(const char* msg);
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #109 am: 21. February 2009, 01:02 »
So, thx schon mal.

Ich habe folgendes Problem. Ich habe eine Variable vom Typ uint64_t. Jetzt habe ich einen Zeiger und möchte, dass dessen Wert der Adresse gleich dem Wert der Variable ist. Ich mache das so:

uint64_t dummy;
uint8_t* zeiger;
...
zeiger = (uint8_t*)dummy;

Nur da dummy ja Werte größer gleich 4 GByte annehmen kann, gibts unter x86 folgende Meldung von gcc:

Zitat
error: cast to pointer from integer of different size

Wie bringe ich dem gcc jetzt bei, dass der Wert der Variablen dummy zu diesem Zeitpunkt nicht größer gleich 4 GByte ist?

thx

bitmaster

EDIT: Tjo nach dem Posten ist mir die Lösung eingefallen, sry.

So geht es:

zeiger = (uint8_t*)((uintptr_t)dummy);
« Letzte Änderung: 21. February 2009, 01:12 von bitmaster »
In the Future everyone will need OS-64!!!

 

Einloggen