Storlek på en integer?

[Gäst al6]

Tjabba, har gått omkring och tänkt på en sak som ja måste få konfirmerad. Jag läser en bok om C++ där det står att en integer har olika storlek i olika "system". Vissa har 4 byte, andra har 2, osv.

Jag menar att det måste handla om själva kompilatorn när dom snackar om "system", eftersom det vore totalt hopplöst att göra ett pålitligt program som ändrade storlek på sina datatyper på olika operativsystem?

Om man tex ska spara X och Y av ett fönster när det stängs, för att sedan starta fönstret där, nästa körtillfälle, skulle jag skrivit:

fileOut << X << Y;

Vilket skule skriva ut 4 * 2 byte (om mitt program är kompilerat med integers av 4 byte)

och sen läsa det med:

fileIn >> X >> Y;

Då måste ju mitt program veta hur stor en integer är för att läsa rätt antal byte av filen!?

Slutfråga: Det är väl kompilatorn som bestämmer alla storlekar av datatyperna (integers o sånt), sen vad man kör för operativsystem kvittar, däremot om man ska kompilera sin källkod på olika "system" DÅ kan de göra skillnad eftersom man har olika kompilatorer, som i sin tur kanske bestämmer olika storlekar, eller hur ?

Okej allt jag vill veta är om jag har rätt eller fel, jag vill bara få detta konfirmerat så jag är 100% på vad jag håller på med

[Gäst al6]

Jag gick tillbaka i boken och läste lite, det verkar som att jag har delvis rätt. Jag får det till att:

Operativsystemet bestämmer storlekarna -> kompilatorn använder dessa storlekar när källkoden ska kompileras. Nu använder programmet samma storlek som den kompilerades med, oavsett operativsystemet som det körs på.

Dock verkar detta vara fel, eftersom det finns fördefinierade värden i limits.h - som inte alls verkar bero på operativsystemet, utan helt bero på själva implementeringen av kompilatorn:

/***

*limits.h - implementation dependent values

*

*      Copyright © Microsoft Corporation.  All rights reserved.

...

#define UINT_MAX      0xffffffff    /* maximum unsigned int value */

Jag menar headerfilerna skrivs ju knappast om i Visual Studio 2008 för att du installerar det på ett annat operativsystem!?

Så åter till mitt påstående: storlekarna är 100% beroende av kompilatorn och har inget med operativsystemet att göra. När programmet är kompilerat ändras aldrig storlekarna.

Snälla svara på detta för jag blir galen om jag inte får svar på detta. Det verkar helt luddigt i boken!

[waxinator]

Då måste ju mitt program veta hur stor en integer är för att läsa rätt antal byte av filen!?

Integer betyder Heltal som kan vara positiva och negativa värden (dvs inga decimaler).

Hur stort heltal en variabel skall kunna beskriva definieras i början av programmet.

Det är upp till programmets behov, hur många byte som skall reserveras per variabel.

Skall programmet rita punkter på min widescreen så skall punkter mellan (x,y) 0,0 - 1680,1050 adresseras.

För detta ändamål behövs 2 * 12 bits (24 bits / 8 = 3 byte) för att beskriva alla punkter.

Det är väl kompilatorn som bestämmer alla storlekar av datatyperna (integers o sånt)

Nej, det definierar programmeraren i programmets inledning.

Kompilatorn optimerar koden till en exekverbar image (exe-fil).

Kompilatorn bakar in hänvisningar till biblioteksfiler (DLL-filer) i målsystemet om så önskas.

På så vis anpassas en generell programkod till olika operativsystem.

[Gäst al6]

Okej men du menar att när programmet väl är kompilerat och man har sin exefil så är storlekarna satta, vilket gör att mitt program kan skriva en integer till en fil, och sen ta den filen till ett helt annat operativsystem och läsa rätt antal bytes - eftersom programmet är det samma och vet hur stor en integer är, sant?

[Zap]

Kompilatorn bestämmer storleken på de olika typerna.

Dess max och minvärden skall dock finnas specade i en limits.h eller climits (c++) fil.

ANSI-C definierar dock vissa minigränser för vad oliak typer skall klara.

[Gäst al6]

Jag har fått svar på min huvudfråga som är att efter kompilering så är storlekarna satta - så långt är vi överräns, tack för alla svar som lett till detta

Men det seanste inlägget vill jag säga är mer rätt, eftersom det verkligen finns en headerfil med alla gränserna satta - och den headerfilen tillhör ju kompilatorn, eller om man så vill implementeringen.

Att det sedan finns minimigrändser är också helt rätt. Jag förstår allt nu, detta är ju en sån sak man inte lägger ner så mycket krut på, förrän man verkligen behöver veta hur det funkar. Det var som jag trodde från början, men nu är jag 100% säker

Jag tror dock inte att waxinator har fel, ja tror nog vi inte pratar om samma språk. Jag pratar om den senaste standarden för C++.

Nej, det definierar programmeraren i programmets inledning.

Detta låter helt främmande för mig, men du kanske menar något annat språk? Kanske assembly?

I alla fall så har jag fått mina svar, så tack till er alla

[Gäst al6]

Ja nu är mysteriet verkligen löst; jag läste i boken igen och startade någon sida före det började bli luddigt, för att förstå hela sammanhanget Med "system" menar min bok utvecklingsverktygen + operativsystemet. Det blev luddigt i och med denna mening:

"Anta t.ex. att ditt program flyttas från en DOS-PC med 16-bitars int till ett system med Windows XP som använder 32-bitars int."

Först verkar det som att, som jag tidigare var helt vimsig angående, att det är operativsystemet som bestämmer storlekarna (fel). Men om man läser hela sammanhanget förstår man att boken inte syftar på att det är Windows XP som använder 32-bitars int, utan att det är dina utvecklingsprogram (kompilatorn) som använder 32 bitar till varje int.

Nu är allt under kontroll igen :)

[plun]

Njau... jag tycker som glad amatörknådare att det verkar vimsigt... 

Kompilatorn kollar ju i vilken miljö som en källkod hamnat för att kunna tillverka binärer

som då ska stödjas av ett operativ.

Headerfiler behövs ju enbart för att kunna kompilera.

Sen kan man göra en integer oändlig.... vanligt förekommande för att tillverka säkerhetshål 

Slutligen så är ju inte en kompilering särskilt komplicerad....  Linux då "she bang"...

Cairographics innehåller väl det mesta som du pular med verkar det som, även kompatibelt med

Windowsmiljön inkl enklare knytningar mot python

[Gäst al6]

(Till plun)

Altså, detta är redan löst, och om du läser inläggen så är det allt annat än vimsigt att förstå.

I stort sett är allt du skrev helt omotiverat?

Vad du menar med en oändlig integer kan jag bara drömma om, eftersom vi i dessa inläggen kommit fram till att alla integers har en fixerad storlek, sen är det ju alltid fiffigt att lägga till ordet säkerhetshål för att verka smart!  >

Sen det där Cairographics är ju (vad mina sökningar visar) ett 2D grafikbibliotek - och du pratar om phyton? (Detta är om integers i C++!)

Jag menar what the fuck gör du i min tråd?! Jag är så jävla trött på sånna här skitinlägg som bara har i syfte att reta upp, och ge falsk information! Skaffa fakta och skriv den på ett motiverat och moget sätt i en passande tråd! Detta inlägget gagnar ingen kan jag säga dig.

Tråden är LÖST.

[plun]

mart!  >

Sen det där Cairographics är ju (vad mina sökningar visar) ett 2D grafikbibliotek - och du pratar om phyton? (Detta är om integers i C++!)

Jo jag satt och läste om integers och Cairo för ett tag sedan angående ett säkerhetshål där

man enkelt manipulerade just integers till oändliga heltal.

Sedan är då Cairo just C, om det är C++ har jag inte kollat

Slutligen angående intresset för just Cairo är att Firefox 3 kör den grafikmotorn då med stöd

för alla plattformar.

http://cairographics.org/

(just nu långa svarstider pga stort intresse och Firefox 3)

[Zap]

Cairo ett 2d grafikbibliotek i standrad C, inte C++.

Så det har ganska lite med storleken av en standard integer att göra.

I alla fall ser jag inte sambandet.

Plun har du länken till vad du läste om säkerhetshålet?

[plun]

Jo nu är jag kanske grinig.... via en enkel google sökning  8)

http://www.google.se/search?q=cairo+intege...lient=firefox-a

Det här blev "omdebatterat" bla pga Firefox 3 som gör Cairo brännhett för utvecklare samt

även de som tillverkar säkerhetshål.

Sedan innehåller då Cairo websidan mycket exempel men det är kanske bättre att läsa någon gammal bok...

De flesta knådarna behärskar ju inte sedan C eller C++ fullt ut i början utan väljer

utvecklingsmiljöer med enklare kopplingar som mot python, sedan när de behärskar

C så kan man köra fullt ut.  Pango är väl ett annat exempel. 

Har man pengar så kan man ju roa sig i .net, visual knådandet...

[Gäst al6]

På första träffen står det nada om att någon integer skulle vara "oändlig" - däremot att man kan göra en integer overflow.

will trigger an integer overflow and execute arbitrary code

När en integer tilldelas ett värde som ligger utanför dess gränser, nollställs den och börjar om. Sånna här fel sker oftast i samband med filer som läses (typ en PNGbild) - eftersom dessa kan ändras så att de innehåller större tal än vad programmet vill ha. Detta felet i samband med pekare hit och dit kan mycket väl få programmet att göra en felaktig hoppsats till en pekare som pekar på annan kod (förmodligen som ligger i PNGbilden), som nu har fått ordet i datorn.

Det handlar inte om att man gör ett säkerhetshål, de uppstår när man inte har koll på sin källkod.

Jag själv anser att detta inlägget var informerande och välformulerat, till skillnad från pluns skitinlägg.

[plun]

Jag själv anser att detta inlägget var informerande och välformulerat, till skillnad från pluns skitinlägg.

Jo läs du din bok så håller jag mig till verkligheten där man tillverkar källkod..

[Zap]

Felet i fallet som Plun talar om verkar vara att png avkodaren i Cairo biblioteket

inte verkar vara helt buggfritt kodad med avseende på vissa heltal som slår runt.

Utan att veta så är en ren teori:

Att man genom att skapa en egen "png bild" och ladda upp den till en hemsida kan få tex Firefox att köra kod i bilden när den i verkligheten tror att den ritar upp bilden på användarens skärm.

Ganska intressanta saker, man måste sätta sig in i hur png avkodaren fungerar relativt bra för att fixa det.

Men källkoden går ju att ladda ner, så det är inget supersvårt direkt.

[Gäst al6]

Testa gärna mitt simpla program ja gjorde precis som sparar positionen av fönstret som två integers i en fil, för att sedan visa fönstret på samma ställe som det avslutades på

www.alux.rr.nu/Position.exe

Sen den där fina kommentaren jag fick precis parerar jag med att säga att du, plun, borde kolla vem som har fått en fast tråd i programeringsforumet, överst, där jag ger ut mitt Quail till alla Javaprogrammerare.

Försök hitta bättre kvalité på samma sorts produkt - gratis! Det finns ju alltid det där JSmooth som suger totalt, det kan inte änns sätta en rätt ikon på projektet och ta upp ca 400 kb. Vad tar mitt Quail upp? Jo 6 kb, funkar på Windows 95 - Vista!

Vem lever i verkligheten och skapar kvalitétskällkod som uppskattas?!

[Zap]

Jag roade i alla fall mig med att kolla på buggfixarna som de gjorde i png avkodaren.

Det är några malloc som allokerar minne, hur mycket minne som skall allokeras bestäms tex av vad det står i bildefilen att den har för höjd. Numera kollar man att minnet man skall allokera inte är större än en maxint.