C, varning datatyp

[lillahuset]

Just det men lite förvillande blev det.

[mri]

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.

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

Lite gammal tråd, men eftersom jag sitter på MISRA C kurs vill jag kommentera den.
ThomasL anser att <stdint.h> som introducerades med C99 på nåt sätt är dåligt, och hänvisar till MISRA C. Det här är ett missförstånd. Rule 13 i den äldre MISRA C standarden han citerar säger inte att man alltid skall skapa egna datatyper.

I den senaste MISRA C standarden (MISRA C:2012) har detta blivit förtydligat ytterligare och den säger uttryckligen att man SKALL använda <stdint.h>, om kompilatorn har den.

Dir 4.6 typedefs that indicate size and signedness should be used in place of the basic numerical types

Category Advisory

Applies to C90, C99

Amplification

The basic numerical types of char, int, long, long long (C99), float, double, and long double should not be used, but specific-length typedefs should be used.

For C99, the types provided by <stdint.h> should be used. For C90, equivalent types should be defined and used

Dvs, om <stdint.h> finns skall den användas, i annat fall kan man själv bli tvungen att typdeffa en motsvarighet.

[lillahuset]

[Nerre]

Liten språk-pekpinne här bara.

Det står "should", d.v.s. "bör", inte SKALL ("shall").

[mri]

Sant, detta är dessutom ett Advisory direktiv, dvs det är tillåtet att avika utan att följa den formella avvikelse processen i standarden. Men de här direktiven finns med av en orsak och bör följas. Nåväl, detta är interna detaljer inom Misra och är inte relevant i sammanhanget.

[extradrajven]

Jag programmerar en del C och funderar på att studera MISRA.

Det här med att inte använda språkets heltalstyper, utan istället vara hänvisad till typer med påtvingad representation tycker jag känns konstigt. Det är ju standardiserat i språket vilka (minsta) intervall som variabler av typerna char, short, int och så vidare kan anta. Dessutom är int den "naturaliga" typen för arkitekturen och man bör få bäst prestanda med den. size_t är typen för sizeof, strlen och så vidare.

Hur är det med konstruktioner som denna?

Kod: Markera allt

int i;
for (i = 0; i < 10; i++) {
  foo();
}

Vad är anledningen till att MISRA rekommenderar fasta längder istället för kompilatorns/arkitekturens naturliga typer? C:s inbyggda typer är ju redan portabla om man håller sig inom standardens intervall.

Vid drivrutinsprogrammering så ska man naturligtvis använda typer med känd representation (stdint.h).

[TomasL]

Problemet är att längden inte är standardiserad, i vissa miljöer kan en char vara 12 bitar i vissa är den 4 bitar, osv.
Det finns alltså ingen som helst specifikation på hur stor en datatyp är, det är helt och hållet maskinberoende.
Därför rekommenderar man att hårdtypa längden , så koden blir portabel till alla system.
Det enda C specificerar är att en char är den minsta datatyp som kan hålla arkitekturens teckenlängd, och att en inte är större än en char.
Så länge man kör med ASCII så är en char 8 bitar, men det finns ju andra teckensystem.
Om man tänker sig en arkitektur som nativt hanterar unicode, så blir ju en char 16 bitar, och en int är då större än en char, så........

[extradrajven]

TomasL:
Språkets heltalstypers garanterade intervall är definierade i C-standarden.
Exempelvis garanteras att en variabel av typen int kan anta värden i intervallet [−32767, +32767]. En signed char kan (garanterat) ha värden i intervallet [-127, +127] och så vidare.

Se exempelvis "The C programming language" eller http://www.open-std.org/jtc1/sc22/wg14/ ... /n1256.pdf (sidan 22).

[Icecap]

Problemet är likaväl om man tar genvägar i programmeringen och räknar med att en char bara har en storlek på 8 bit (eller short är 16 bit osv).

Det är fullt legalt enl. standarden att alla värden är 32 bit store som exempel.

Jag testade att skriva ut storleken (sizeof()) de olika värden då jag lärde känna GCC + Renesas och med C90 var float och double samma storlek, long long hade samma storlek som long osv.

Detta fick jag dock löst vid att använda C99 eller C11.

[TomasL]

extradrajven: inte Ansi C enligt K&R, där definieras en char som en typ, med en minsta längd som kan hålla hela systemets nativa teckenuppsättning, dvs normalt ASCII och då är den 8 bitar.

[Nerre]

Ja, det stora problemet är väl att standarden främst definierar en minsta längd.

Det har ju tagits upp exempel här där både char och int var 32 bitar.

I många fall är det viktigt att veta inte bara minsta längden utan den verkliga längden, för att t.ex. veta om man behöver göra en cast i samband med ett vänsterskift eller liknande.

Eller om data ska sparas ner på disk. Om en char är 32 bitar så kommer all data att ta 4 gånger så mycket plats som om man använt en typ som är specificerad till 8 bitar.

[TomasL]

Dessutom när standarden definierar den som en relativ storlek.
Normalt inga problem när man håller sig inom samma processorfamilj, men skall man skriva portabla program så kan det skapa stora problem.

[bearing]

När jag skriver kod till en 32-bit µC frestas jag att använda uint32_t för räknare som ska räkna från typ 0 till 10, eftersom uint32_t är snabbare än uint8_t. Men koden skulle ju bli väldigt fläskig om den skulle portas till en 8-bitare senare.

Fast det kanske finns någon sätt runt detta. Någon sorts variabel datatyp. Som "int"

Int är faktiskt 8-bit signed i (minst) en kompilator avsedd för 8-bits µC. Den går ifrån standarden en smula.

[lillahuset]

extradrajven: Läs om din referens och gör det lite noggrannare så kommer du att backa.

Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

[TomasL]

bearing, C enligt K&R säger väl att en int skall vara minst lika stor som en char, så en int och en char kan i vissa miljöer vara lika stora.