Haciendo 'largos' 4 bytes en gcc en una máquina Linux de 64 bits

Estoy trabajando en portar una aplicación a 64 bits en la plataforma Linux. La aplicación actualmente es compatible con Linux, Windows, Mac de 32 bits y Windows de 64 bits. Uno de los problemas que nos encontramos con frecuencia es el uso de long para int y viceversa. Esto no fue un problema hasta ahora, ya que long e int son intercambiables (ambos son 4 bytes) en las plataformas en las que actualmente se admite la aplicación. La base de código es enorme, con una gran cantidad de código heredado con #defines para muchos tipos de datos, hace que sea engorroso buscar todo el uso de largo y reemplazar apropiadamente con int.Haciendo 'largos' 4 bytes en gcc en una máquina Linux de 64 bits

Como solución a corto plazo, ¿hay alguna manera de hacer que GCC use 4 bytes en lugar de 8 para "long"?
Si es así, ¿cuáles son los problemas que podríamos enfrentar? Si no, ¿hay una manera más fácil de solucionar el problema largo e int?

Fuente

2012-10-09 Chethan Ravindranath

Esto no es una solución para su problema inmediato (de ahí el comentario), pero en el futuro usaría tipos de ancho exactos (por ejemplo, 'uint32_t'). –

No. En Linux x86_64 la ABI especifica que siempre es un tipo de 8 bytes (LP64). De hecho, la mayoría, si no todos, los sistemas Unix de 64 bits (incluido OS X de 64 bits, AFAIK) son LP64, por lo que no es nada específico de Linux.
Más allá de corregir su código, no.

Si necesita un tipo entero portátil que es lo suficientemente grande como para almacenar un valor de puntero, utilice intptr_t o uintptr_t (pero por lo general querer almacenar un valor de puntero en un entero significa que estás haciendo algo mal, por lo ¡pensar dos veces!). Para un tipo entero que sea capaz de representar la diferencia entre dos punteros, use ptrdiff_t. Para tamaños de objetos, use size_t.

Fuente

2012-10-09 07:55:32 janneb

Si las bibliotecas en tiempo de ejecución están vinculadas estáticamente, al ABI no debería importar qué tipo el compilador llama "largo", siempre que los prototipos de la biblioteca externa se definan utilizando tipos de ancho fijo y el compilador no intente hacer molestos cosas con aliasing de tipos que tienen la misma representación pero no coinciden. – supercat

-m32 genera el código de 32 bits.

-mx32 genera código de 64 bits pero utiliza punteros y largos de 32 bits.

Intel 386 and AMD x86-64 Options

Fuente

2012-10-09 07:22:00

Pero, ¿cómo podría eso interactuar con las bibliotecas del sistema utilizando largos de 64 bits? – johv

El póster original parece necesitar 32 bits, por lo que deben vincularse a las bibliotecas que funcionan con datos de 32 bits. Creo que cuando se llama a una función, cuando necesita un parámetro de 32 bits, no importa qué tipo de datos tiene la persona que llama, y no le importa si la persona que llama era una función C. Pero sí, la persona que llama debe asegurarse de no llamar a una biblioteca que espera valores de 64 bits. –

@johv: No lo hará. Con -m32 necesita utilizar bibliotecas con el ABI x86 de 32 bits "habitual", con -mx32 necesita bibliotecas X32. – janneb

Haciendo 'largos' 4 bytes en gcc en una máquina Linux de 64 bits

Respuesta

Cuestiones relacionadas