Svenska ElektronikForumet

> varför Char[4] inte är samma sak som en long?

Jag skulle just posta det att du skriver ut *pekaren* till första
tecknet i din char[4], inte innehåller som sådant, men det såg
ju flera...

Men din fråga. Ja, båda skrivsätten kommer att allokera 4 bytes i minnet.
Men C i sig hanterar dessa "variabler" ganska olika.

När du skriver LongLBA så är det alltid innehållet/värdet som används.
Du kan även ange att du vill använda andessen med "&LongLBA".

När du skriver CharLBA så kommer C att avända *adressen* till CharLBA,
inte innehållet som sådant. Du kan komma åt innehåller på några olika sätt.
Du har redan fått metoden med en cast, och det fungerar ju. Här är ett par till.
Det som är inläst är "ABCD" (41424344 i hex) från en fil: Det ger:

Tack för förklarandet sodjan
Jag har lärt mig en sak idag ialf

Att koda med att använda en castad char[4] istället för en long, är väl att be om problem.
Förstår inte varför du inte använder en long, som tänkt är i stället.

Nä för att testa. Jag såg inte varför det inte skulle funka, så jag testade. Så nu har jag lärt mig lite mer hur Char fungerar

gkar skrev:För att göra en enkel sak lite mer komlicerad.

De olika datatyperna i C varierar kraftigt mellan olika arktekturer. En char kan vara 8 eller 16 bitar, eller där imellan.
En long är längre än en int, och en int kan vara 16 eller någoting annat, vilket gör att en long kan vara 17bitar även om jag akdrig sett en sådan long.

Det finns visst maskiner med 64 (!) bitars char också.

17 bitars long skulle dock inte gå då standarden kräver vissa minsta omfång för de olika typerna. För long är det +-(2^31-1) för signed long och 0-(2^32-1) för unsigned long, men det är fritt fram att ha större omfång på long än så (i praktiken fler bitar).

Här finns en liten lista:
http://stackoverflow.com/questions/6155 ... 32-64-bits

Nja, det är väl inte bara char utan allt vad som heter typer i C.
dessutom kan du aldrig vara säker på hur lång en typ är.

char - Smallest addressable unit of the machine that can contain basic character set. It is an integer type
short/short int - större än char.
int - större än char, oftast större än short.
long/long int - större än int

Så att räkna med att en typ är ett visst antal tecken lång, är helt felaktigt, och man får jätteproblem.

> long/long int - större än int

Inte alltid, ibland är de av samma längd: http://pic.dhe.ibm.com/infocenter/zos/v ... ndards.htm

kimmen skrev:

gkar skrev:För att göra en enkel sak lite mer komlicerad.

De olika datatyperna i C varierar kraftigt mellan olika arktekturer. En char kan vara 8 eller 16 bitar, eller där imellan.
En long är längre än en int, och en int kan vara 16 eller någoting annat, vilket gör att en long kan vara 17bitar även om jag akdrig sett en sådan long.

17 bitars long skulle dock inte gå då standarden kräver vissa minsta omfång för de olika typerna. För long är det +-(2^31-1) för signed long och 0-(2^32-1) för unsigned long, men det är fritt fram att ha större omfång på long än så (i praktiken fler bitar).

Är det så?! Visa mig texten i standarden som specificerar long till minst 32bitar.

En long SKALL vara så stor, eller större, att den rymmer en adress. Med andra ord bör en long och en pekare ha samma storlek.

Vilket innebär att om adressområdet är 16 bitar så kan en long vara 16 bitar.
Är adressen större än 32 bitar måste en long vara 64 bitar eller större.

Allt är kanske inte alltid så enkelt och "hugget i sten".

T.ex HP-C för OpenVMS har :
short: 16 bit
int: 32 bit
long: 32 bit
long long: 64 bit

Sedan kan pekare vara 32 eller 64 bitar, default är 32 bit.
Det styrs med en switch till kompilatorn eller ett #pragma
i själva koden (så man kan blanda 32 och 64 bit pekare om
man vill). Det här är för 64 bitars maskiner för övrigt. Processer
körs normalt i en 32 bitars virtuell adressrymd, men det finns
rutiner som malloc64() för att allokera minne från 64 bitars
adressrymden (vilket malloc() ändras till om man har begärt
64 bitars pekare). Notera att definitionen av "long" dock
inte påverkas av att man kör 64 bit pekare.

gkar skrev: Är det så?! Visa mig texten i standarden som specificerar long till minst 32bitar.

ISO/IEC 9899:TC2
"5.2.4.2.1 Sizes of integer types <limits.h>
— minimum value for an object of type long int
LONG_MIN -2147483647 // −(231 − 1)
— maximum value for an object of type long int
LONG_MAX +2147483647 // 231 − 1
— maximum value for an object of type unsigned long int
ULONG_MAX 4294967295 // 232 − 1
"
Dvs en long måste vara minst 32 bitar.

baron3d skrev:En long SKALL vara så stor, eller större, att den rymmer en adress. Med andra ord bör en long och en pekare ha samma storlek.

Vilket innebär att om adressområdet är 16 bitar så kan en long vara 16 bitar.
Är adressen större än 32 bitar måste en long vara 64 bitar eller större.

Enligt vilken standard?

C-standarden kräver att long skall effektivt ha minst 32 bitar för att uppfylla kravet på numeriskt omfång.
Jag är inte så insatt i just det, men möjligen krävs i POSIX-standarden att long skall kunna representera en pekare, men det ingår inte i C-standarden vad jag vet.

Ett exempel där long är kortare än pekare är 64-bitars Windows där long (och int) är 32 bitar medan pekare är 64 bitar.

Lämpliga typer för att (någorlunda) portabelt och standardmässigt räkna på pekare som tal är väl uintptr_t, intptr_t och ptrdiff_t.

kimmen du har rätt.

Hade en lärare som "lärde" mig detta. Har efter lite googlande sett att det är fel.

Det är väl det största misstaget i C-språkets historia att de inte definierade heltalstyperna fast. Det hade inte varit svårt att uppkalla dem efter antal bitar, eller varför inte antal bytes? Är det lika tokigt i C++ och C# att de har ärvt denna förvirring?

Det kan så vara.
Ofta bättre att använda typerna som är i stdint.h:
int8_t, int16_t, int32_t, etc ...
och hoppas att det fungerar rätt med maskinen man använder.