2012-10-09 15 views
9

Sto lavorando al porting di un'applicazione a 64 bit su piattaforma Linux. L'applicazione è attualmente supportata su Linux, Windows, Mac a 32 bit e Windows a 64 bit. Uno dei problemi che incontriamo frequentemente è l'uso di long per int e viceversa. Questo non era un problema fino ad ora poiché long e int sono intercambiabili (entrambi sono 4 byte) nelle piattaforme su cui è attualmente supportata l'applicazione. Il codebase è enorme, con un sacco di codice legacy con #defines per molti tipi di dati, rende complicato cercare tutti gli usi di long e sostituirli in modo appropriato con int.Creazione di "lunghi" 4 byte in gcc su una macchina Linux a 64 bit

  1. Come soluzione a breve termine, esiste un modo per far utilizzare a GCC 4 byte anziché 8 per "long"?
  2. In caso affermativo, quali sono i problemi che dovremmo affrontare? In caso contrario, c'è un modo più semplice per risolvere il problema long e int?
+5

Questa non è una soluzione per il tuo problema immediato (da qui il commento), ma per il codice futuro userei invece tipi di larghezza esatta (ad esempio, 'uint32_t'). –

risposta

6
  1. No. In Linux x86_64 ABI specifica che lungo è un tipo 8 byte (LP64). In effetti, la maggior parte se non tutti i sistemi Unix a 64 bit (incluso OS X a 64 bit, AFAIK) sono LP64 quindi non è niente di specifico per Linux.

  2. Oltre a fissare il codice, no.

Se avete bisogno di un tipo integer portatile che è abbastanza grande per memorizzare un valore di puntatore, utilizzare intptr_t o uintptr_t (ma di solito vogliono memorizzare un valore di puntatore in un intero significa che si sta facendo qualcosa di sbagliato così, pensa due volte!). Per un tipo intero che è in grado di rappresentare la differenza tra due puntatori, utilizzare ptrdiff_t. Per le dimensioni degli oggetti, usa size_t.

+0

Se le librerie di runtime sono collegate staticamente, l'ABI non dovrebbe preoccuparsi di quale tipo il compilatore chiama "long", a condizione che qualsiasi prototipo di libreria esterna sia definito usando tipi a larghezza fissa e il compilatore non provi a fare fastidiosi cose con aliasing di tipi che hanno la stessa rappresentazione ma non corrispondono. – supercat

5

-m32 genera codice a 32 bit.

-mx32 genera codice a 64 bit ma utilizza caratteri a 32 bit e puntatori.

Intel 386 and AMD x86-64 Options

+0

Ma come interagirebbe con le librerie di sistema usando 64 bit lunghi? – johv

+0

Sembra che il poster originale abbia bisogno di lunghi 32 bit, quindi è necessario collegarsi a librerie che funzionano con dati a 32 bit. Penso che quando viene chiamata una funzione, quando ha bisogno di un parametro a 32 bit, non gli importa quale tipo di dati abbia il chiamante, e non gli importa se il chiamante fosse una funzione C. Ma sì, il chiamante deve essere sicuro di non chiamare una libreria che si aspetta valori a 64 bit. –

+2

@johv: Non lo farà. Con -m32 è necessario utilizzare le librerie con il "solito" ABI a 32 bit a 32 bit, con -mx32 occorrono le librerie X32. – janneb

Problemi correlati