Newsgroup: it.comp.lang.c
Titolo: sizeof(off_t) > sizeof(long long) ?

Saluti.
 
Secondo voi è possibile che, per una certa implementazione, si abbia che
sizeof(off_t) > sizeof(long long) ?
 
Lo standard (POSIX [1]) non lo sembra vietare vietare, ma sarebbe una 
scelta certo curiosa.
 
Lo chiedo perchè in un progetto che sto sviluppando avevo una variabile 
dichiarata come unsigned long long, e formattata con printf utilizzando "%
llu"; tale variabile di recente l'ho modificata in modo da essere di tipo 
off_t, ma mi ero dimenticato di aggiornare la printf.
 
Ora sto facendo un commit con messaggio dettagliato per spiegare perchè 
ho sostituito "%llu" con "%jd", ed ero curioso di sapere se ne valeva la 
pena, dato che probabilmente %llu andava benissimo (il programma è 
compilato in modo da avere sizeof(off_t) >= 64).
 
 
[1] 
http://pubs.opengroup.org/onlinepubs/009695399/utilities/c99.html
 
 
 
Grazie   Manlio Perillo


In generale non puoi mai sapere quanto sono grossi off_t, size_t, ssize_t e
amici. L'unico modo di fare una printf (ma perché poi devi fare una printf
di un off_t??) è fare cast al più grosso intero rappresentabile e stampare
quello (se sei in C99 cast su (uintmax_t) e print con %ju - se non sbaglio
off_t è unsigned, no?)
 
Ciao!

 pena, ...
 
Perché non hai chiesto questo più logicamente e più semplicemente
invece di farti masturbazioni mentali?
 

 
 
Beh, sarebbe "curioso" perché, se si intende strettamente maggiore,
significherebbe che sta lavorando su un sistema che permette di gestire
file più grossi di 2^64 (che è la dimensione minima per un long long)! :)
 
Ciao!

 
 
E' signed.
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html
 
 
 
Ciao   Manlio


Non mi sembra che gli  standard dicano qualcosa sulla size di off_t
Certo, come dici, sarebbe alquanto curioso o strano se fosse > di 
sizeof(long long)
 
Per la formattazione, se sei interessato ad un pò di portabilità, puoi 
mettere un test con il preprocessore tipo
 
#if sizeof(off_t) == sizeof(int)
printf("%d\n", off_t_var);
#elif sizeof(off_t) == sizeof(long)
printf("%ld\n", off_t_var);
#elif sizeof(off_t) == sizeof(long long)
printf("%lld\n", off_t_var);
#else
#error  "what is the size of off_t ?"
#endif
 
 
 

 
 
My bad. Allora stessa cosa con (intmax_t) e "%jd".. ma credo tu l'abbia già
fatto, no? ;)
 
Ciao!
 
P.S. Per curiosità: ma su che piattaforma ti è capitato questo problema?
L'unica cosa per cui mi viene in mente per un discrepanza simile è in cross
compiling per piattaforme più grosse della nativa quando si sbaglia a fare
link con le libc (eh, questo mi è capitato una volta e me lo ricorderò a
vita, maledette CFLAGS di sistema).

 
 
In effetti ci sono filesystems che permettono files più grossi di 2^64.
Ad esempio Btrfs supporta files fino 16 EiB (ma su Linux il limite è 8 
EiB).
 
 
Ciao  Manlio

 lo ricorderò a vita, maledette CFLAGS di sistema).
 
Mai avuto a che fare con cross compiling...
 
 
Ciao  Manlio

 
 
Beh, non c'è nulla di differente rispetto ad una compilazione normale, a patto
che il sistema di build (make, gcc/ld sotto, o chi di dovere su macchine
diverse) utilizzino tutti gli stessi identici settaggi.
A me è venuto in mente perché mi è capitato qualcosa di simile per errore in
quel caso, da qui la mia curiosità.
 
Comunque, per tagliare la testa al topo e coprirsi anche dai casi più
improbabili, penso abbiamo scritto tutte le soluzioni più in voga ;)
 
Ciao!

 file più grossi di 2^64 (che è la dimensione minima per un long long)! :)
 
Eccola lì, un altro pieno di pregiudizi stupidi. Perché dei file di venti
exabyte sarebbero tanto strani? Il tuo modo di pensare è da perdenti, 
da scimmie ammaestrate che dovrebbero stare alla larga dai computer.
 
Pensare che un limite sia troppo grande e che sia irraggiungibile 
produce solo bug e soluzioni poco efficiente. Ormai i dischi 
per i casalinghi si parla di terabyte, applicazioni neanche troppo 
particolari richiedono capacita di storage dell'ordine del petabyte,
e già un singolo esperimento del CERN produce qualcosa come 
ventitré petabyte di dati da analizzare. Se pensi che 2^64 sia un
limite invalicabile ti troverai a dover riprogettare tutta la tua 
infrastruttura tra due o tre anni perché tra due o tre anni la
quantità di dati che dovrai processare sarà aumentata di dieci 
volte e il tuo filesytem sarà obsoleto.
 
E infatti già ti hanno fatto notare che già esistono sistemi che 
trattano gli hexabyte.
 

 trattano gli hexabyte.
 
Sì, tutto bello tutto giusto. Peccato è che né io né te sviluppiamo qualche
implementazione ufficiale della libc, per cui bisogna solo guardare quello che
chi di dovere fa e trarre le nostre conclusioni in base alla situazione
attuale.
 
Ciao!
 
P.S. Se invece sei uno degli sviluppatori di una di quelle implementazioni
che ci citavo e che però non conosco, please link al repository, così mi tengo
aggiornato!

 trattano gli hexabyte.
 
Esistono filesystems a 128 bits, ed i processori a 64 bits come per 
l'architettura AMD-64 supportano interi a 128bits.
 
Però a me interessa (come curiosità) più che altro sapere se e **quali** 
implementazioni implementano il tipo long long come int64 e off_t come 
int128.
 
 
Ciao  Manlio

 base alla situazione attuale.
 
CHE CI APPIZZA? La possibilità di trattare dati a 128 bit o a 256 bit
dipende dal processore, non dalle specifiche del linguaggio, non dalla
libc, e non dai vari standard. E non ostante da  molte parti si dica che
non esistono macchine a 128 bit, non è vero. alcuni VAX e System/
370 IBM permettono operazioni  a 128 bit, molte architetture RISC 
permettono operazioni vettoriali a 128 e 256 bit. E già si parla che 
la crittografia  beneficerebbe di operazioni aritmetiche a 128 e 256 bit.
Come (non) vedi tincerarsi dietro "Ma attualmente nessun processore
usa tipi interi a più di 64 bit" è un modo di vedere miope che poco
aiuta lo sviluppo. Non ci sarà a breve un processore a 128 bit (e 
neanche a lungo termine) ma ATTUALMENTE i processori che
usiamo ogni giorno hanno la potenzialità di trattare dati a 128 bit e 
lo standard C dovrà essere aggiornato, fosse anche  per un solo 
chip dedicato alla crittografia spinta.
 


Non ho capito se:
1- non hai la più pallida idea della differenza di gestione dei vari tipi di
dati a livello di processore, di kernel e di libc, oppure
2- sai quel che dici ma sei così competente che che la questione ti sembra così
assurda che l'ira è l'unica soluzione, oppure
3- fai polemica tanto per farla.
 
No, dimmelo, così posso dare una risposta a tono; per adesso sembra solo che
"butti lì" un sacco di luoghi comuni, senza dare alcuna motivazione.
 
Ciao!

 int128.
 
Non lo so. Buoni candidati IBM AS400, VAX, PowerPC. 
Il mio scopo era dire che non necessariamente long long int e off_t devono
essere uguali o di 64 bit o che il tipo intero più lungo debba essere 64 bit
 

 essere uguali o di 64 bit o che il tipo intero più lungo debba essere 64 bit
 
Nessuno in questo thread ha mai detto niente del genere.

 spinta.
 
Stai scherzando?
Ti pare possibile che lo standard debba essere modificato per ogni nuova 
architettura?
 
Non farti trarre in inganno da long long; ho letto che è stata una 
forzatura (che ha causato molti contrasti) voluta da Microsoft per porre 
rimedio ad un limite del suo sistema [1].  In in pratica Windows per 
sistemi a 64bits supporta solo il modello LLP64, ed in questo 
"sfortunato" modello, int, short e long sono a 32 bit, quindi serviva un 
altro tipo di larghezza 64bits.
 
long long non serve.  Nel mio caso, dovevo tenere conto del numero di 
bytes letti e decompressi, per un file di 9GB compresso e 60GB 
decompresso ed in questo caso va bene off_t; in altri casi ci sono 
int_least_64_t o intmax_t.
 
I recenti standard per il C e POSIX hanno cercato di migliorare la 
situazione; in C con l'addizione di <stdint.h>, ed in POSIX con il 
supporto per i "programming environments" [2]; si noti come nei nomi dei 
modelli con compaia long long, ma off_t.
 
 
[1] 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384083
 
(v=vs.85).aspx
[2] 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/
 
c99.html#tagtcjh_24
 
 
Ciao  Manlio