Newsgroup: it.comp.os.linux.development
Titolo: Cosa accadra' quando avremo interi a 64 bit al nostro software?

Ciao,
se oggi scrivo in C/C++ e scrivo qualcosa come
FILE *F=fopen...
int x=12345678;
fwrite(&x,sizeof(x),1,F);
vengono scritti sul file 4 byte.
Quando arriveranno i processori a 64 bit,
il tipo (int) rimarra' a 32 bit (e di conseguenza 
per avere un intero a 64 bit si scrivera' qualcosa come (long int))
oppure sara' automaticamente promosso a 64 bit ?
Nel secondo caso,il programma ricompilato funzionera' , se scrivo i dati
come sopra e li leggo cosi':
fread(&x,sizeof(x),1,F);
perche' si scriveranno e si leggeranno dal file 64 bit per intero.
Ma i file di dati prodotti dallo stesso software su una piattaforma
a 32 bit, non potranno piu' venire scambiati col nuovo software.
Mi auguro che non sia cosi' sarebbe un altro w2k...

 a 32 bit, non potranno piu' venire scambiati col nuovo software.
mah... è inevitabile che qualsiasi applicazione richieda
operazioni bit a bit, non potrà migrare direttamente
da un sistema all'altro. E' anche vero che non tutti
i programmi utilizzano operazioni di questo genere,
quindi un minimo di esportabilità dovrebbe essere
garantita.
ciao
luke

 a 32 bit, non potranno piu' venire scambiati col nuovo software.
Gia` oggi scrivere dei dati cosi` vuol  dire farsi del male. E se il tuo
programma viene usato su una  macchina con endianess diverso? E se viene
compilato con un compilatore che considera sizeof(int) == 2?
Se vuoi scrivere  dati _binari_ in modo portabile devi  prima definire a
tavolino tutti  i dettagli  del formato. Es. il  file sara`  composto da
interi  senza  senza lunghi  4byte  in  formato little  endian. Poi  nel
programma creri un  layer che si occupa di leggere  il file e "tradurre"
nel formato nativo della macchina.
Oppure (meglio imho) scrivi i  dati come normalissimo testo, magari come
documento XML. In questo caso non avrai problemi.
Luca
-- 
Home: 
http://kronoz.cjb.net
I went to God just to see
And I was looking at me
Saw heaven and hell were lies
When I'm God everyone dies

 
bene, come parziale consolazione vedo che "int"
rimane invariato, e long int non l'ho mai usato.

 documento XML. In questo caso non avrai problemi.
in questo caso non posso, i file saranno molto grandi e scriverli come
testo sarebbe un blobbing inutile e poco accettabile.
Inoltre devo spremere la maggior velocita' possibile.
Grazie, ciao.

 compilato con un compilatore che considera sizeof(int) == 2?
sizeof(int) = 4. E` scritto nello standard.
Ciao,
-- 
       Roberto Divia`             Love at first sight is one of the greatest
       =============             labour-saving devices the world has ever seen.
Mailbox: C02110                 CERN-European Organization for Nuclear Research
E-mail: 
Robert...@cern.ch
           CH-1211 GENEVE 23, Switzerland

 sizeof(int) = 4. E` scritto nello standard.
No. Lo  standard dice  che la  dimensione  _minima_ di  un int  e` di  2
byte.  Non viene specificata la dimensione  di nessun tipo di dato fatta
eccezione per char che e` grande 1 byte, per definizione.
Per i dettagli vedi
5.2.4.2 Numerical Limits
e seguenti.
Luca
-- 
Home: 
http://kronoz.cjb.net
Non sempre quello che viene dopo e` progresso.
Alessandro Manzoni

 
Scusa ma, č possibile che il tipo "unsigned long" occupi spazio diverso
che "long" sulla stessa macchina ? Sulla mia architettura a 32 bit un
"unsigned long" occupa quanto un "long" ovvero 4 byte.
Ciao
Matic

Salove. E' da molto che non frequento questo NG, ma in passato l'ho fattoper
un po'.
Non sono il massimo esperto di UNIX, POSIX e GCC, dato che per un po' mi
sono staccato da Linux e recentemente ci sto ritornando (con molto
entusiasmo a dire il vero... :-)), ma... nella glibc non sono definiti dei
typedef (o magari li consce direttamente il compilatore...) del tipo u16,
u32, etc....?
Non vale la pena, dovendo scrivere comunque non manualmente codice che ha
bisogno di lavorare usando numeri di bit specifici questi tipi, invece di
quelli standard ANSI, tenendo presente che non è difficile usare typedefs
per gestire i porting e che con tutte le implementazioni di gcc sono
disponibili (mi ricordo la stesa cosa addirittura nel portng del gcc per
Game Boy Advance...)?
-- 
Marco Iannaccone
marcoia...@katamail.com
ICQ UIN: 18748121
Parlano, parlano di liberta', ma quando vedono un individuo veramente
libero, allora ne hanno paura.
        da "Easy Rider"

 			sizeof(long long) is at least 64 bits
Questo vuol dire che non potremo mai evere un tipo di base che sia *esattamente*
di N bytes, dove N > 1... Fantastico per chi come me deve scrivere codice
portabile tra macchine a 32 e 64 bit. Meno male che ho messo dei controlli
ovunque nel mio codice.
Grazie,


 ovunque nel mio codice.
Ma i tipi:
int32_t
int64_t
u_int32_t
[...]
Non fanno parte del c99 e forse anche dell'ultimo draft del c++?
Bye,
  Gabry

 ha scritto:

Si`, ma non sono obbligatori :) L'implementazione deve fornire
int_leastN_t
uint_leastN_t
con N  = {8, 16,  32, 64}. Sono tipi interi  (con e senza  segno) grandi
_almeno_ N bit. Tuttavia se un'implementazione fornisce tipi interi a 8,
16,  32 e  64 bit  allora  deve anche  fornire  i typedef  per intN_t  e
uintN_t. Quindi,  a meno  di  casi mooolto  particolari dovresti  essere
tranquillo.
Inoltre  lo  standard  POSIX  estende  l'ISO  rendendo  obbligatoria  la
presenza di  int{8,16,32}_t e uint{8,16,32}_t. La presenza  di int64_t e
uint64_t e`  richiesta solo  se l'implementazione  ha a  disposizione un
tipo a 64 bit.
Luca
-- 
Home: 
http://kronoz.cjb.net
Dicono che  il cane sia  il miglior  amico dell'uomo. Secondo me  non e`
vero. Quanti dei vostri amici avete fatto castrare, recentemente?

> Non fanno parte del c99 e forse anche dell'ultimo draft del c++?
continuo a seguirvi, ragazzi.
continuate, continuate :-)
dai che ne cavo qualcosa di buono..

 tranquillo.
Peccato per l'"almeno", comunque una soluzione ci sarebbe allora:
long pippo; // lungo almeno 4 bytes
fwrite(&pippo, 1, min(sizeof(pippo), 4), file);
Ovviamente e` bruttina, ma dovrebbe esser compatibile con i compilatori 
che rispettano lo standard :)
Bye,
  Gabry

 che rispettano lo standard :)
Beh il  POSIX (e  stiamo parlando  di linux ;))  ti mette  abbastanza al
sicuto con  intN_t. Finche` rimaniamo su  x86, Sparc, Alpha,  PPC, MIPS,
ARM non ci sono problemi.
Le uniche  macchine che  abbia mai  visto con  formati strani  erano dei
"cosi" [1] della Bull-Honeywell. Avevano byte da  9 bit, word a 18 bit e
dword a 36bit. Dubito che qualcuno sia mai riuscito a farci girare linux
;)
Luca
[1] Non veri e propri mainframe... non saprei il termine esatto.
-- 
Home: 
http://kronoz.cjb.net
Il piu` bel momento dell'amore e` quando ci si illude che duri per 
sempre; il piu` brutto, quando ci si accorge che dura da troppo.