Lowlevel
Lowlevel => Softwareentwicklung => Thema gestartet von: FlorianN am 29. October 2012, 19:45
-
Hallo,
wie der Titel schon sagt, habe ich Probleme mit "uint8_t" und GCC. Mein Compiler kennt diesen Befehl (nein, kein Befehl!) nicht. Warscheinlich ist die Lösung sehr einfach aber ich schaffe es trotzdem nicht. Was ist das überhaupt? Eine Art int?
Freue mich schon auf Antworten, Florian
-
uint8_t ist eine vorzeichenlose, 8-bittige Ganzzahl, d.h. Sie kann Werte von 0 bis 255 annehmen.
Sie wird vom OS (!) in stdint.h wie folgt definiert:
typedef unsigned char uint8_t;Aber glaub mir: Lern bitte erstmal ein paar C-Grundlagen. Zu wissen, was in stdint.h steht, gehört wirklich zu den Basics.
-
Sie wird vom OS (!) in stdint.h wie folgt definiert:
typedef unsigned char uint8_t;Aber glaub mir: Lern bitte erstmal ein paar C-Grundlagen. Zu wissen, was in stdint.h steht, gehört wirklich zu den Basics.
Die solltest du auch lernen ;)
Die wird nicht vom OS, sondern vom Compiler, nicht eingetragen, sondern mitgeliefert, in Form der stdint.h. Im C/C++ Standard steht nämlich leider nicht ganz genau welcher Datentyp immer wie groß ist. Deswegen ist bzw. war das Compiler abhängig.
-
Aber glaub mir: Lern bitte erstmal ein paar C-Grundlagen. Zu wissen, was in stdint.h steht, gehört wirklich zu den Basics.
Ich habe ein C-Buch zuhause. Ich habe dort extra nachgeschaut bevor ich die Frage im Forum gestellt habe. Dort stand nichts!
-
Solche Datentypen gehören nicht zu C, der Programmiersprache, sondern zu C, dem Standard. ;-)
-
Sie wird vom OS (!) in stdint.h wie folgt definiert:
typedef unsigned char uint8_t;Aber glaub mir: Lern bitte erstmal ein paar C-Grundlagen. Zu wissen, was in stdint.h steht, gehört wirklich zu den Basics.
Die solltest du auch lernen ;)
Die wird nicht vom OS, sondern vom Compiler, nicht eingetragen, sondern mitgeliefert, in Form der stdint.h. Im C/C++ Standard steht nämlich leider nicht ganz genau welcher Datentyp immer wie groß ist. Deswegen ist bzw. war das Compiler abhängig.
Ich möchte wirklich keinen Flamewar starten, denn ich bin kein C-Guru und irgendwann würde ich dann irgendetwas Falsches sagen, worüber dann alle herfallen...
Aber trotzdem muss ich ein wenig Kontra geben:
- GCC liefert, so wie ich das verstanden habe, für "Notfälle" zwar diese Header mit. Eigentlich werden sie aber von der libc (bei Linux glibc) bereitgestellt, die wiederum den C-Standard implentiert. (siehe z.B. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448))
- Ich habe nie eingetragen gesagt, sondern definiert. Letztendlich wird in diesen Headern aber in etwa das oben dargestellte stehen.
- Wenn man aber OS-Dever ist, will man normalerweise nicht die Header des Host-OS verwenden -> Deshalb sollte man immer mit -ffreestanding -no-stdinc -no-stdlib kompilieren, damit man nicht am Ende bestimmte glibc-Parts im Image hat.
Florian, ich empfehle osdevlibc (http://code.google.com/p/osdevlibc/). Sie ist zwar keine vollständige libc, hat aber alle wichtigen Funktionen für den Start dabei und stellt keine Anforderungen. (Achtung, das printf() der osdevlibc ist unvollständig, da musst du noch den OS-spezifischen Part dazuschreiben)
So, und jetzt haut euch (bzw. mir) die Köpfe ein...
-
Also, wie gesagt, die werden nicht vom OS mitgeliefert bzw. auf die sollte man sich im Fall des Falles nicht verlassen, weil jeder Compiler die unterschiedlich definieren kann (wie groß ein int ist z.B.) und deswegen wird das vom Compiler in Form der stdint.h mitgeliefert.
Das wird besonders deutlich wenn du einen Cross-Compiler nutzt und z.B. für einen Mikrocontroller Code erzeugst. Da wird auch keine stdint.h vom OS genommen, sondern die die zum entsprechendem Compiler dazu gehört, weil die Datentypen halt unterschiedlich groß sind.
Heutzutage ist das mit den unterschiedlichen Größen der Datentypen nicht mehr so schlimm, da sich die Compiler-Hersteller auf die selben Werte geeinigt haben (war früher nicht so). Es gibt jetzt halt "nur" noch die Unterschiede zw. den Architekturen.
-
Also, wie gesagt, die werden nicht vom OS mitgeliefert bzw. auf die sollte man sich im Fall des Falles nicht verlassen, weil jeder Compiler die unterschiedlich definieren kann (wie groß ein int ist z.B.) und deswegen wird das vom Compiler in Form der stdint.h mitgeliefert.
Das ist es ja: Wir programmieren hier selber das OS und ich hab ihm gezeigt, wie uint8_t in stdint.h definiert werden sollte. Da er wahrscheinlich nicht schon die glibc portiert hat, läuft es ja darauf hinaus das er in einem include-Verzeichnis selber stdint.h erstellt.
Das wird besonders deutlich wenn du einen Cross-Compiler nutzt und z.B. für einen Mikrocontroller Code erzeugst. Da wird auch keine stdint.h vom OS genommen, sondern die die zum entsprechendem Compiler dazu gehört, weil die Datentypen halt unterschiedlich groß sind.
Hab ich das nicht gerade gesagt?
"GCC liefert, so wie ich das verstanden habe, für "Notfälle" zwar diese Header mit. Eigentlich werden sie aber von der libc (bei Linux glibc) bereitgestellt, die wiederum den C-Standard implentiert. (siehe z.B. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448))"
Heutzutage ist das mit den unterschiedlichen Größen der Datentypen nicht mehr so schlimm, da sich die Compiler-Hersteller auf die selben Werte geeinigt haben (war früher nicht so). Es gibt jetzt halt "nur" noch die Unterschiede zw. den Architekturen.
Ja.
-
Ich habe im GGC mal nachgeschaut.
Auschschnitt aus \MinGW\include\stdint.h | Z.27-34:
typedef signed char int8_t;
typedef unsigned char uint8_t;
typedef short int16_t;
typedef unsigned short uint16_t;
typedef int int32_t;
typedef unsigned uint32_t;
typedef long long int64_t;
typedef unsigned long long uint64_t;
In der 2. Zeile von oben steht es:
typedef unsigned char uint8_t;
Habe ich einfach oben in meinem C-Programm eingefügt. Es hat funktioniert!
MfG, Florian
-
Habe ich das nicht im ersten Post schon mal erwähnt?
-
Habe ich das nicht im ersten Post schon mal erwähnt?
Ja, hast du. Ich wollte es nur nocheinmal zur Verdeutlichung schreiben. Man erkennt hier z.B. auch uint32_t.
-
Für aufstrebende C-Programmierer gibt es an anderer Stelle spezielle Foren zum Lernen der Sprache. Alternativ brauch man nicht notwendigerweise Programmierkenntnisse, um einen Open-Source-Kernel - ein Linux etwa - selbst zu kompilieren.