PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : uint32_t Definition fehlt



Siro
17.06.2010, 14:32
Hallo zusammen, ich hoffe ich stelle diese Frage nicht doppelt,
ich habe aber noch keine problemslösende Info hier gefunden.

Wo finde ich die Definition des Typs:

uint32_t bei der IAR-Embedded Workbench.

Ja, ich weis, jetzt werdet ihr mir sagen ich muss die Datei stdint.h includieren. Das ist auch völlig korrekt. Aber in dieser Datei wird nur der Typ benutzt, die Definition selbst fehlt jedoch.

Damit nicht evtl. eine andere Datei includiert wird, ich habe 21 Stück davon auf meiner Platte gefunden, habe ich im C-Code sogar den gesamten Pfad angegeben. So konnte ich sicherstellen, das auch wirklich die Datei aus dem entsprechenden Verzeichnis benutzt wird.

#include "C:\Programme\IAR Systems\Embedded Workbench 5.4 Kickstart\arm\inc\stdint.h"

Sobald ich in meinem Projekt die include Datei "stdint.h" ausklammere, findert der Compiler unter anderem den Type uint32_t nicht.
Aber in der Datei selbst befindet sich gar keine Definition des Typs uint32_t
Sobald ich sie aber includiere, sind die Fehler verschwunden.

Natürlich kann ich auch eine andere Datei aus einem anderen Verzeichnis benutzen, die sind dann aber nicht von IAR zugeliefert worden und das
beantwortet auch nicht die Frage.

ich stell mal den Code dieser Datei hier ein: (mit dem Hinweis des Copyrights von IAR Systems)

Hier werden noch 2 zusätzliche Dateien includiert ycheck.h und yvals.h
dort befindet sich aber auch nicht die gesuchte Definition. Habe ich schon durchforstet.


/* stdint.h standard header */
/* Copyright (C) 2003 IAR Systems. All rights reserved. */
#ifndef _STDINT
#define _STDINT

#ifndef _SYSTEM_BUILD
#pragma system_include
#endif

#include <ycheck.h>
#include <yvals.h>
_C_STD_BEGIN

/* Fixed size types. These are all optional. */
#ifdef __INT8_T_TYPE__
typedef __INT8_T_TYPE__ int8_t;
typedef __UINT8_T_TYPE__ uint8_t;
#endif /* __INT8_T_TYPE__ */

#ifdef __INT16_T_TYPE__
typedef __INT16_T_TYPE__ int16_t;
typedef __UINT16_T_TYPE__ uint16_t;
#endif /* __INT16_T_TYPE__ */

#ifdef __INT32_T_TYPE__
typedef __INT32_T_TYPE__ int32_t;
typedef __UINT32_T_TYPE__ uint32_t;
#endif /* __INT32_T_TYPE__ */

#ifdef __INT64_T_TYPE__
typedef __INT64_T_TYPE__ int64_t;
typedef __UINT64_T_TYPE__ uint64_t;
#endif /* __INT64_T_TYPE__ */

/* Types capable of holding at least a certain number of bits.
These are not optional for the sizes 8, 16, 32, 64. */
typedef __INT_LEAST8_T_TYPE__ int_least8_t;
typedef __UINT_LEAST8_T_TYPE__ uint_least8_t;

typedef __INT_LEAST16_T_TYPE__ int_least16_t;
typedef __UINT_LEAST16_T_TYPE__ uint_least16_t;

typedef __INT_LEAST32_T_TYPE__ int_least32_t;
typedef __UINT_LEAST32_T_TYPE__ uint_least32_t;

/* This isn't really optional, but make it so for now. */
#ifdef __INT_LEAST64_T_TYPE__
typedef __INT_LEAST64_T_TYPE__ int_least64_t;
#endif /* __INT_LEAST64_T_TYPE__ */
#ifdef __UINT_LEAST64_T_TYPE__
typedef __UINT_LEAST64_T_TYPE__ uint_least64_t;
#endif /* __UINT_LEAST64_T_TYPE__ */

/* The fastest type holding at least a certain number of bits.
These are not optional for the size 8, 16, 32, 64.
For now, the 64 bit size is optional in IAR compilers. */
typedef __INT_FAST8_T_TYPE__ int_fast8_t;
typedef __UINT_FAST8_T_TYPE__ uint_fast8_t;

typedef __INT_FAST16_T_TYPE__ int_fast16_t;
typedef __UINT_FAST16_T_TYPE__ uint_fast16_t;

typedef __INT_FAST32_T_TYPE__ int_fast32_t;
typedef __UINT_FAST32_T_TYPE__ uint_fast32_t;

#ifdef __INT_FAST64_T_TYPE__
typedef __INT_FAST64_T_TYPE__ int_fast64_t;
#endif /* __INT_FAST64_T_TYPE__ */

#ifdef __UINT_FAST64_T_TYPE__
typedef __UINT_FAST64_T_TYPE__ uint_fast64_t;
#endif /* __UINT_FAST64_T_TYPE__ */

/* The integer type capable of holding the largest number of bits. */
typedef __INTMAX_T_TYPE__ intmax_t;
typedef __UINTMAX_T_TYPE__ uintmax_t;

/* An integer type large enough to be able to hold a pointer.
This is optional, but always supported in IAR compilers. */
typedef __INTPTR_T_TYPE__ intptr_t;
typedef __UINTPTR_T_TYPE__ uintptr_t;

/* An integer capable of holding a pointer to a specific memory type. */
#define __DATA_PTR_MEM_HELPER1__(M, I) \
typedef __DATA_MEM##I##_INTPTR_TYPE__ M##_intptr_t; \
typedef __DATA_MEM##I##_UINTPTR_TYPE__ M##_uintptr_t;
__DATA_PTR_MEMORY_LIST1__()
#undef __DATA_PTR_MEM_HELPER1__

/* Minimum and maximum limits. */
#if !defined(__cplusplus) || defined(__STDC_LIMIT_MACROS)

#ifdef __INT8_T_TYPE__
#define INT8_MAX __INT8_T_MAX__
#define INT8_MIN __INT8_T_MIN__
#define UINT8_MAX __UINT8_T_MAX__
#endif

#ifdef __INT16_T_TYPE__
#define INT16_MAX __INT16_T_MAX__
#define INT16_MIN __INT16_T_MIN__
#define UINT16_MAX __UINT16_T_MAX__
#endif

#ifdef __INT32_T_TYPE__
#define INT32_MAX __INT32_T_MAX__
#define INT32_MIN __INT32_T_MIN__
#define UINT32_MAX __UINT32_T_MAX__
#endif

#ifdef __INT64_T_TYPE__
#define INT64_MAX __INT64_T_MAX__
#define INT64_MIN __INT64_T_MIN__
#define UINT64_MAX __UINT64_T_MAX__
#endif

#define INT_LEAST8_MAX __INT_LEAST8_T_MAX__
#define INT_LEAST8_MIN __INT_LEAST8_T_MIN__
#define UINT_LEAST8_MAX __UINT_LEAST8_T_MAX__

#define INT_LEAST16_MAX __INT_LEAST16_T_MAX__
#define INT_LEAST16_MIN __INT_LEAST16_T_MIN__
#define UINT_LEAST16_MAX __UINT_LEAST16_T_MAX__

#define INT_LEAST32_MAX __INT_LEAST32_T_MAX__
#define INT_LEAST32_MIN __INT_LEAST32_T_MIN__
#define UINT_LEAST32_MAX __UINT_LEAST32_T_MAX__

#ifdef __INT_LEAST64_T_TYPE__
#define INT_LEAST64_MAX __INT_LEAST64_T_MAX__
#define INT_LEAST64_MIN __INT_LEAST64_T_MIN__
#endif

#ifdef __UINT_LEAST64_T_TYPE__
#define UINT_LEAST64_MAX __UINT_LEAST64_T_MAX__
#endif

#define INT_FAST8_MAX __INT_FAST8_T_MAX__
#define INT_FAST8_MIN __INT_FAST8_T_MIN__
#define UINT_FAST8_MAX __UINT_FAST8_T_MAX__

#define INT_FAST16_MAX __INT_FAST16_T_MAX__
#define INT_FAST16_MIN __INT_FAST16_T_MIN__
#define UINT_FAST16_MAX __UINT_FAST16_T_MAX__

#define INT_FAST32_MAX __INT_FAST32_T_MAX__
#define INT_FAST32_MIN __INT_FAST32_T_MIN__
#define UINT_FAST32_MAX __UINT_FAST32_T_MAX__

#ifdef __INT_FAST64_T_TYPE__
#define INT_FAST64_MAX __INT_FAST64_T_MAX__
#define INT_FAST64_MIN __INT_FAST64_T_MIN__
#endif

#ifdef __UINT_FAST64_T_TYPE__
#define UINT_FAST64_MAX __UINT_FAST64_T_MAX__
#endif

#define INTMAX_MAX __INTMAX_T_MAX__
#define INTMAX_MIN __INTMAX_T_MIN__
#define UINTMAX_MAX __UINTMAX_T_MAX__

#define SIZE_MAX __SIZE_T_MAX__

#define PTRDIFF_MAX __PTRDIFF_T_MAX__
#define PTRDIFF_MIN __PTRDIFF_T_MIN__

#define INTPTR_MAX __INTPTR_T_MAX__
#define INTPTR_MIN __INTPTR_T_MIN__
#define UINTPTR_MAX __UINTPTR_T_MAX__

#define WCHAR_MIN _WCMIN
#define WCHAR_MAX _WCMAX

#define WINT_MIN _WIMIN
#define WINT_MAX _WIMAX

#define SIG_ATOMIC_MIN __SIGNED_CHAR_MIN__
#define SIG_ATOMIC_MAX __SIGNED_CHAR_MAX__


#endif /* !defined(__cplusplus) || defined(__STDC_LIMIT_MACROS) */


/* Macros expanding to integer constants. */
#if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS)

#ifdef __INT8_T_TYPE__
#define INT8_C(x) _GLUE(x,__INT8_C_SUFFIX__)
#define UINT8_C(x) _GLUE(x,__UINT8_C_SUFFIX__)
#endif

#ifdef __INT16_T_TYPE__
#define INT16_C(x) _GLUE(x,__INT16_C_SUFFIX__)
#define UINT16_C(x) _GLUE(x,__UINT16_C_SUFFIX__)
#endif

#ifdef __INT32_T_TYPE__
#define INT32_C(x) _GLUE(x,__INT32_C_SUFFIX__)
#define UINT32_C(x) _GLUE(x,__UINT32_C_SUFFIX__)
#endif

#ifdef __INT_LEAST64_T_TYPE__
#define INT64_C(x) _GLUE(x,__INT64_C_SUFFIX__)
#endif

#ifdef __UINT_LEAST64_T_TYPE__
#define UINT64_C(x) _GLUE(x,__UINT64_C_SUFFIX__)
#endif

#define INTMAX_C(x) _GLUE(x,__INTMAX_C_SUFFIX__)
#define UINTMAX_C(x) _GLUE(x,__UINTMAX_C_SUFFIX__)

#endif /* !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS) */

_C_STD_END
#endif /* _STDINT */
[/b]

für jegliche Info bedanke ich mich schon im voraus,
Siro

sternst
17.06.2010, 14:48
Aber in der Datei selbst befindet sich gar keine Definition des Typs uint32_t Und was ist dies:
typedef __UINT32_T_TYPE__ uint32_t; ???


Sobald ich sie aber includiere, sind die Fehler verschwunden. Was ist denn dann eigentlich das Problem?

Siro
17.06.2010, 20:19
Danke Dir vorab,

okay, wenn uint32_t vom type __UINT32_T_TYPE__ ist,
dann müste aber der Typ __UINT32_T_TYPE__ irgendwo beschrieben sein.

Mein Problem ist einfach, das ich es verstehen will:

Woher weis der Compiler, das ein uint32_t einem vermutlich "unsigned long" entspricht, das muss doch irgendwo stehen.
Das kann ich der Datei selbst aber nicht entnehmen.

Die Zeile typedef __UINT32_T_TYPE__ uint32_t;
kann alles mögliche sein, da ich nicht weis wie __UINT32_T_TYPE__ definiert ist.

mfg. Siro

sternst
17.06.2010, 23:28
okay, wenn uint32_t vom type __UINT32_T_TYPE__ ist,
dann müste aber der Typ __UINT32_T_TYPE__ irgendwo beschrieben sein.Nein, muss er nicht. __UINT32_T_TYPE__ ist offenbar etwas Compiler-Internes (wofür auch die beiden führenden Unterstriche sprechen).


Woher weis der Compiler, das ein uint32_t einem vermutlich "unsigned long" entspricht, das muss doch irgendwo stehen.
Das kann ich der Datei selbst aber nicht entnehmen.

Die Zeile typedef __UINT32_T_TYPE__ uint32_t;
kann alles mögliche sein, da ich nicht weis wie __UINT32_T_TYPE__ definiert ist. Das ist doch auch alles total uninteressant. Der C-Standard sichert dir für uint32_t gewisse Eigenschaften zu, nämlich dass es ein unsigned Integer mit der Größe 32 Bit ist. Wenn ein "unsigned long" diese Bedingungen erfüllt, dann kann die Programmierumgebung ein uint32_t auf ein "unsigned long" zurückführen, muss es aber nicht. Es kann den Typ auch auf einen x-beliebigen anderen Typ mit diesen Eigenschaften zurückführen (hier __UINT32_T_TYPE__). Für dich interessant sind nur die zugesicherten Eigenschaften, nicht wie der Compiler das nun genau realisiert.

PS: Beim AVR-GCC sieht es z.B. noch verwirrender aus:

typedef int int8_t __attribute__((__mode__(__QI__)));
typedef unsigned int uint8_t __attribute__((__mode__(__QI__)));
typedef int int16_t __attribute__((__mode__(__HI__)));
typedef unsigned int uint16_t __attribute__((__mode__(__HI__)));
typedef int int32_t __attribute__((__mode__(__SI__)));
typedef unsigned int uint32_t __attribute__((__mode__(__SI__)));
#if !__USING_MINT8
typedef int int64_t __attribute__((__mode__(__DI__)));
typedef unsigned int uint64_t __attribute__((__mode__(__DI__)));Da werden alle diese Typen auf "int" und "unsigned int" zurückgeführt, allerdings mit zusätzlichen Attributen, die wohl die genaue Größe festlegen. Aber auch hier gilt dann: was ein "unsigned int" mit zusätzlichem Attribut "__mode__(__SI__)" genau ist, interessiert nicht wirklich. Hauptsache der daraus gebildete Typ uint32_t hat die zugesicherten Eigenschaften.

Siro
18.06.2010, 02:38
Ich beziehe mich mal auf deinen Satz:

Der C-Standard sichert dir für uint32_t gewisse Eigenschaften zu, nämlich dass es ein unsigned Integer mit der Größe 32 Bit ist

Das "vermutest" Du (ich auch, keine Frage) , aber das ist doch nicht sichergestellt, solange es nirgens definiert ist.

Ich könnte doch eine Definition machen, die wie folgt aussieht:

typedef unsigned char uint32_t

dies würde bedeuten, daß sämtliche Variablen oder Register nur noch 8 Bit breit sind.

Und genau da sehe ich das Problem, es muss doch irgendwo festgelegt werden, wie diese Definition aussieht. Und genau danach suche ich.

Ich weis schon, daß die Register irgendwie als 32 Bit definiert sind. Aber wo, das finde ich nicht.
Vom Verständnis her, brauchen wir uns nicht weiter zu unterhalten, weil Du, genau wie ich weis, das es sich um
32 Bit Werte handelt. Ich suche doch nur, wo diese Definition festgelegt wird.
Ich wüste nicht, daß in ANSI-C festgelegt wurde, das ein uint32_t
immer einen 32 Bit Wert wiederspiegelt. Also muss es irgendwo festgelegt (definiert) sein.
und das konnte ich in der beschriebenen Datei bisher nicht finden.

Schade, daß nur wir zwei uns Gedanken darüber machen, das sind doch meiner Meinung nach ganz grundlegende
Dinge. Dein Beispiel vom GNU GCC verwundert mich nichtmal, da auch IAR "irrwitzige" Definitionen hat.
Da gibt es zum Beispiel __IO was dann lediglich als "volatile" definiert ist.

So, nun wünsche ich noch ein Softwarereiches Wochenende.
mit freundlichen Bits,
Siro

askazo
18.06.2010, 07:44
Der C-Standard sichert dir für uint32_t gewisse Eigenschaften zu, nämlich dass es ein unsigned Integer mit der Größe 32 Bit ist

Das "vermutest" Du (ich auch, keine Frage) , aber das ist doch nicht sichergestellt, solange es nirgens definiert ist.

Ich denke, Du solltest dem Compiler-Hersteller einfach mal ein wenig vertrauen. Unter Umständen wirst Du die Definition auch irgendwo im Manual finden. Und wenn Du ganz sichergehen willst, kannst Du immer noch den sizeof-Operator verwenden, um die Größe zu kontrollieren...

Gruß,
askazo

oberallgeier
18.06.2010, 09:51
... es muss doch irgendwo festgelegt werden, wie diese Definition aussieht. Und genau danach suche ich ...Ok, Deine Frage steht im Forum unter "... (GC C u.a.) ...", Du selbst schreibst von " ... bei der IAR-Embedded Workbench ...".

Zu IAR-Embedded Workbench kann ich nix sagen. Zum GC C im AVRStudio gibts ein av r-libc-user-manual, in dem Typdefinitionen der stdint.h in allen verfügbaren Varianten beschrieben sind. Hier (klick) (file:///C:/Programme/WinAVR-20090313/doc/avr-libc/avr-libc-user-manual/group__avr__stdint.html#gdb828ef50c2dbb783109824e9 4cf6c47) beispielsweise die typedef signed long int int32_t. Und wenn Dir das nicht reicht, gibts im www noch mehr, denn

If you find yourself stuck on a problem which this document doesn't quite address, you may wish to post a message to the avr-gcc mailing list.Ansonsten stimme ich Stefan zu (dem stimme ich eigentlich IMMER zu *ggg*) - vertraue den Compilerbauern. Alternativ: bau Dir einen Compiler selber - dann weißt Du es gaaanz genau.

sternst
18.06.2010, 11:57
Das "vermutest" Du (ich auch, keine Frage) , aber das ist doch nicht sichergestellt, solange es nirgens definiert ist.
Wie gesagt: Es ist im C-Standard definiert.


Ich könnte doch eine Definition machen, die wie folgt aussieht:

typedef unsigned char uint32_t

dies würde bedeuten, daß sämtliche Variablen oder Register nur noch 8 Bit breit sind.
Das wäre dann aber kein C mehr, weil es dem C-Standard widersprechen würde. Davon abgesehen, ein char muss nicht 8 Bit groß sein, es könnte durchaus auch 32 Bit groß sein. Und wieso eigentlich spiegelt bei dir die Größe von einem uint32_t die Größe sämtlicher Variablen und Register wieder?


Ich wüste nicht, daß in ANSI-C festgelegt wurde, das ein uint32_t
immer einen 32 Bit Wert wiederspiegelt.ANSI-C ist schon lange nicht mehr der gültige Standard. Such nach "ISO/IEC 9899".

sternst
18.06.2010, 12:17
Ok, Deine Frage steht im Forum unter "... (GC C u.a.) ...", Du selbst schreibst von " ... bei der IAR-Embedded Workbench ...".Und? IAR fällt doch wohl unter das "u.a.". ;)


beispielsweise die typedef signed long int int32_t.So steht es aber nur in der Dokumentation, um den Leser nicht zu verwirren, denn die echte Definition sieht so aus:

typedef int int32_t __attribute__ ((__mode__ (__SI__)));
(nur so als Info)

sternst
18.06.2010, 12:28
Und als kleiner Extra-Service hier der entsprechende Passus aus dem aktuellen C-Standard:

7.18.1.1 Exact-width integer types

1 The typedef name intN_t designates a signed integer type with width N, nopadding bits, and a two’s complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits.

2 The typedef name uintN_t designates an unsigned integer type with width N. Thus, uint24_t denotes an unsigned integer type with a width of exactly 24 bits.

3 These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two’s complement representation, it shall define the corresponding typedef names.

oberallgeier
18.06.2010, 14:12
... So steht es aber nur in der Dokumentation, um den Leser nicht zu verwirren, denn die echte Definition sieht ...Ich hatte angenommen, dass der wissbegierige Leser die stdint.h schon gelesen hätte (ich hatte es das soundsovielte Mal, wieder nur teilweise - und kenn sie immer noch nicht auswendig : ( ). Meine Annahme, dass die stdint.h gelesen wird, scheint aber nicht Standard-C zu sein. Leider sagte mir "IAR" nix im Software-Kontext, das kannte ich nur aus flugzeugbauerischer Sicht.

Siro
19.06.2010, 18:49
Hallo zusammen,
eigentlich hatte ich es schon fast aufgegeben, weiter nach den Definitionen zu suchen. (nicht wirklich, ich gebe nie auf)
Aber siehe da, hier kamen doch noch ganz wichtige Informationen für rein.
Dafür möcht ich mich bedanken.

bei "Stefan" mit dem Hinweis "ISO/IEC 9899"
Super, da steht doch nun wirklich einiges (alles) drin. 556 Seiten. Hab zwar noch nicht alle gelesen, aber genug um meine Aussage zu revidieren. Da gibt es ja tatsächlich die besagte Definition.
Dein "Extra-Service" ist also dankend angekommen.

Die stdint.h habe ich natürlich gelesen. Okay sagen wir überflogen... :-) Davon habe ich, wie ich schon erwähnte, 21 Stück auf der Platte. Natürlich NICHT mit gleichem Inhalt. Von einer 4 KByte großen Version von "Microchip" bis zur 12 K Byte großen Datei von Yagarto.
WinArm hat auch andere und IAR natürlich auch wieder, achja Keil sieht auch wieder anders aus. Na wie dem auch sei, ich geb mich mal mit den Informationen zufrieden und möchte mich bei den beteiligten
bedanken. Die nächsten Fragen kommen bestimmt...

Siro

SprinterSB
23.06.2010, 15:10
Die stdint.h habe ich natürlich gelesen. Okay sagen wir überflogen... :-) Davon habe ich, wie ich schon erwähnte, 21 Stück auf der Platte. Natürlich NICHT mit gleichem Inhalt. Von einer 4 KByte großen Version von "Microchip" bis zur 12 K Byte großen Datei von Yagarto.
WinArm hat auch andere und IAR natürlich auch wieder, achja Keil sieht auch wieder anders aus.

Warum sollten die gleich sein?
Die können (und werden) unterschiedliche Compiler-Interna verwenden, um die zu definierenden Typen darauf abzubilden (zB Attribute bei avr-gcc)
Die Typen können unterschiedlich sein. Ein uint_fast8_t wird auf einem 8-Bit System anders aussehen als auf einem 32-Bit System.
Sie können sich in den Kommentaren unterscheiden (Doxygen, Lizenz, komplett ohne Doku, ...)
Sie können sich in der Reihenfolge der Definitionen unterscheiden
Andere Zeilenumbrüche (DOS, UNIX, ...)