C, varning datatyp

[thomasloven]

Det är de två metoder jag kan komma på också.
Men om man nu inte kan lita på stdint.h - som distrubueras med kompilatorkedjan, är perfekt avpassad för just det system du kompilerar mot och genomgår automatiserad testning efter varje förändring, hur ska man då kunna lita på dokumentationen - som i många fall bara är kopierad från en långt tidigare version av samma kompilator avsedd för en helt annan processorarkitektur, om den överhuvudtaget finns?
Därför undrar jag lite över TomasLs resonemang och undrar om han har någon tredje metod - det finns ju mycket om c som jag inte känner till.

Men kanske borde det startas en ny tråd om detta, om det är fler än jag som är intresserade av att ta den här diskussionen vidare?

[Mr Andersson]

sizeof() är mycket användbar om man är osäker på en typstorlek. Och eftersom storleksberäkningen sker vid kompilering behöver man inte ens köra koden för att testa.
Om du har tillgång till static_assert (C++11) eller _Static_assert (C-11):

Kod: Markera allt

static_assert(sizeof(int) == 4, "int is not 32 bits!");

Eller ett litet "fulhack" som borde fungera på alla C/C++-kompilatorer

Kod: Markera allt

#define STATIC_ASSERT(expr) typedef char _ASSERT_TEST_[(expr) ? 1 : -1]
STATIC_ASSERT(sizeof(int) == 4);

I bägge fallen får man kompileringsfel om int inte är 4B/32b men static_assert är lite snyggare för du kan skriva ett beskrivande felmeddelande. Med array-versionen får du ett (kanske lite kryptiskt för utomstående) felmeddelande om att arrayer inte kan ha negativ längd.

Edit:
Ovanstående fungerar bara på system där 1 byte = 8 bitar.

[victor_passe]

TIs C2000 kärna har char=16bit, den mcun kan inte hantera 8bit.

[Icecap]

Jag blev överraskat då jag började med Renesas RX. Själva µC'n var helt OK men kompilern hade sina sidor.

Jag testade att skriva ut sizeof() på alla variabeltyper och det var intressant.
_UBYTE (unsigned char) & _SBYTE (signed char) var 1 byte stor, helt väntat.
_UWORD (unsigned short) & _SWORD (signed char) var 2 byte stor, helt väntat.
_UDWORD (unsigned long) & _SDWORD (signed long) var 4 byte stor, helt väntat.
_UQWORD (unsigned long long) & _SQWORD (signed long long) var 4 byte stor, HELT OVÄNTAT.
float var 4 bytes stor, helt väntat.
double var 4 bytes stor, HELT OVÄNTAT.

Men nu använder jag en switch som ger mig C99 och nu är _xQWORD och double båda 8 bytes stor, helt som jag väntar mig.

Så det är inte µC'n som ger problem, det är kompilern. Och i C89 (ANSI + K&R) finns ingen "standardvariabel" över 4 bytes och detta är orsaken till att jag switchar in C99.

Men som det skrivs:
C-standarden garanterar bara att det finns en minsta storlek på heltalsvariabler, inget annat.
Flyttal är på minst 4 bytes - och det är vad som garanteras.

Så att skriva ut storleken kan vara en mycket bra idé om man vill vara säker och då jag ibland har värden som kan bli mycket stora och definitivt göra anspråk på mer än 32 bit har jag säkrat mig vid att skriva ut storlekarna så att jag vet.

Under C89 lyckades jag faktisk att räkna med long long (64 bit) men att skriva ut värdet kunde jag glömma! Jag fick göra en egen rutin för att skriva ut sådana värden och det fick mig att kolla på hur det kunde lösas och i mitt fall var lösningen C99.

[lillahuset]

Kompilatorn (TIs egen) jag använde till TMS320C3x hade bara en storlek på variabeltyper, 32 bit och sizeof() alla variabeltyper var 1.

[thebolt]

Om alla heltalstyper var 32-bit (vilket är ok enl. standard C89/99) så måste sizeof() också vara 1 för alla, då sizeof mäter storlek i antal "char sized units" (dvs sizeof(char) == 1 per definition). C(99) definierar minsta möjliga range som man måste kunna lagra i en typ, men typerna kan vara större än så.

[Mr Andersson]

> då sizeof mäter storlek i antal "char sized units"

Varför inte bara kalla det bytes, som standarden gör? Visst, "char sized units" är ju samma sak men det låter, iaf. enligt mig, mer förvirrande.

[adent]

Nja sizeof() på den processor lillahuset skriver om ger ju 1 på samtliga typer, alla 32 bitar. Alltså inte bytes utan char-sized.

[lillahuset]

Och som thebolt missade, troligen beroende på mig, var även flyttalen 32 bit och sizeof även i det fallet 1.
Nu hade TMS320C3x 40 bits flyttal om man använde assembler. Och det hade vi stor glädje av. Viva assembler!

[superx]

40-bitars flyttal? Samma med Analog Devices Sharc också har då!

[lillahuset]

Jag hade för mig att ADI Sharc var snäppet vassare med 48 bit men inser efter en snabb koll att jag minns fel. 40 bit är ju rätt lagom om man vill köra en MAC 256 loopar eller mindre.
Vi körde ett IIR-filter för integrering som blev för dåligt med 32 bits flyttal så då var det ju bra att vi kunde köra lite assembler. Sa surgubben.

[superx]

48-bit är ju för adresserna till programminnet ju.

[lillahuset]

Kollade igen och de 48 bittarna jag for efter var instruktionsbredden.
https://en.wikipedia.org/wiki/Super_Har ... p_Computer

Hur bred är ackumulatorn? Jag hittade inget om det på ADIs hemsida. Det finns naturligtvis där men jag tycker deras sida har blivit väldigt svårhanterlig.

[superx]

Ja, det var ju det jag menade såklart. 48-bitarsinstruktioner, men adresserna är fortfarande 32-bitar (men räknade i 48-bitarsord).

Tror att ackumulatorn är 80-bitar, iaf för fixed point. För flyttal kanske det är 40-bitar?

[Mr Andersson]

Nja sizeof() på den processor lillahuset skriver om ger ju 1 på samtliga typer, alla 32 bitar. Alltså inte bytes utan char-sized.

Standarderna (c89, c99 & c11) säger:
sizeof-resultat anges i bytes.
sizeof(char) ska vara 1.

Och det betyder att:
char är alltid 1 byte stor
Antal bitar per byte är arkitektursspecifikt.