Svenska ElektronikForumet

TomasL: Varför då?

Annars så har jag varit med om att en char är 32 bit och sizeof(char) är 1. TI C för TMS320C3x.

I stdint.h har kompilatortillverkaren typdefinierat standardtyper så att du kan skriva portabel kod (lättare).

Kolla i den filen.

Du kommer hitta datatyperna int8_t, int16_t, int32_t, uint8_t, uint16_t, uint32_t bland annat. Använd dom.

Personligen, litar jag inte på dessa.

Av den enkla anledningen

Rule 13 (advisory)
This rule states that an application should not directly use basic types such as char, int, float etc. Instead specific-length equivalents should be typedefed for the specific compiler, and these type names should be used in the code. The reason is that different compilers could use different underlying representation for the basic types. The most common case is the type int that could be seen as 16 bit wide by one compiler and 32 bit wide by another.

Detta från MISRA.
Just därför skall man typa ina egna variabler, fr att inte få några överaskningar.

Visst, det kan säkert finnas uint_8 osv, men man kan ju aldrig vara säker, speciellt inte när det gäller C

TomasL: Det är sådan som du smo ger C dåligt rykte.

Edit: inte smo utan som.
Edit igen: inte sådan utan sådant Läggdags tror jag,

Nejdå, bara goda råd.

Vad är problemet med stdint.h?

Säkert inga problem, men som allting i C, man kan inte vara riktigt säker på nånting.
Vilket naurligtvis är det roliga med just C, allting är tillåtet, typ, och att det kan bli katastrof, när man inte har 100 koll.

Finns den så har jag aldrig hört talas om att det är något problem. Men den saknades ju länge i Visual Studio, vilket var/är väldigt irriterande. Går såklart att skriva en egen för att komma runt just det problemet.

Förresten så är standarden (C99) tydlig vad det gäller just stdint.h som jag mins det.

superx: C99 och nyare må vara det men C89 är inte. Och ANSI C är C89, något som används väldigt mycket.

Problemet är sällan att det blir fel när man gör en rutin och återanvänder den inom samma µC-familj (t.ex. 8 bit -> 8 bit), problemet är att säkerställa att man kan använda en funktion från t.ex. PIC/8051/ATmega (8 bit) på t.ex. 32-bitars ARM/Renesas eller liknande.

C är i mångt och mycket ett bra språk för att det är så tillåtande. Samtidig kan man göra dundertabbar just för att det är så tillåtande och de kan vara skitsvåra att hitta.

Jag använder själv fula knep ibland, t.ex. att fixa åtkomst till en WORD-baserat buffer på BYTE-nivå, helt enkelt för att spara tid under utskanningen av ett bildminne. Den µC jag använder kan väljas att köra Little Endian eller Big Endian så väljer man fel Endian är den rutin "död" (om nu inte jag hade fixat det vid att kolla Endian och skriva två versioner).

Nu var det dock ev. fel i stdint.h vi diskuterade, så C99 var väl underförstått så som jag förstod det. Men visst, det kan finnas behov av egna typedefs och makron, men jag skulle inte rekommendera det som standardlösningen. Risken att man själv gör fel är ju inte obefintlig direkt, och om man kan använda något som kompilatortillverkaren tillhandahåller och som testas av många användare tror jag det är bättre.

Det är väl liksom tanken.

TomasL skrev:Nä, gör inte det, eftersom det kan skapa problem.
Skapa alltid egna datatyper med den längd du vill ha.
När det gäller just char, s är den definierad enligt K&R som den minsta datatypen som kan hålla en full teckenuppsättning för systemet i fråga, dvs normalt handlar det då om ASCII, dvs 8 bitar.

Hur ger du dina datatyper en bestämd längd?

Du läser i manualen till din C-kompilator.
Där står längden på alla datatyper.

Står det att en short är 16bitar så skriver du: typedef signed short sint16;
och: typedef unsigned short uint16;

En long brukar vara 32bitar:
typedef signed long sint32;
typedef unsigned long uint32;

Helst bör man använda stdint.h.

Mitt minne av vad en char är är "den minsta adresserbara enheten" men det kan vara fel. Minnet är inte vad det varit. Möjligen skiljer det mellan K&R och ANSI.