Tworzenie "długich" 4 bajtów w gcc na 64-bitowym komputerze z Linuksem

Pracuję nad przeniesieniem aplikacji na platformę 64-bitową na platformę Linux. Aplikacja jest obecnie obsługiwana w systemach Linux, Windows, Macintosh 32-bit i Windows 64-bit. Jednym z problemów, z którymi często się spotykamy, jest używanie długich na int i na odwrót. Nie stanowiło to problemu do tej pory, ponieważ long i int są wymienne (oba są 4 bajtami) na platformach, na których aplikacja jest obecnie obsługiwana. Baza kodowa jest ogromna, z dużą ilością starszego kodu z #defines dla wielu typów danych, sprawia, że trudno jest przeszukiwać całe użycie długich i zastąpić odpowiednio int.Tworzenie "długich" 4 bajtów w gcc na 64-bitowym komputerze z Linuksem

W krótkiej perspektywie rozwiązanie, czy jest jakiś sposób, aby użyć GCC 4 bajty zamiast 8 dla „długi”?
Jeśli tak, jakie problemy możemy napotkać? Jeśli nie, czy istnieje łatwiejszy sposób na naprawienie problemu długiego i int?

Źródło

2012-10-09 Chethan Ravindranath

To nie jest rozwiązanie dla twojego bezpośredniego problemu (stąd komentarz), ale dla przyszłego kodu użyłbym zamiast tego dokładnych typów szerokości (np. 'Uint32_t'). –

No. W systemie Linux x86_64 ABI określa, że długo to typ 8 bajtów (LP64). W rzeczywistości większość, jeśli nie wszystkie 64-bitowe systemy uniksowe (w tym 64-bitowe OS X, AFAIK) to LP64, więc nie jest to nic szczególnego dla Linuksa.
Poza naprawianiem kodu, nie.

Jeśli potrzebujesz przenośnego typu Liczba całkowita, która jest na tyle duża, aby zapisać wartość wskaźnika, należy intptr_t lub uintptr_t (ale zazwyczaj chcąc zapisać wartość wskaźnika na liczbę całkowitą oznacza, że robisz coś złego, tak Pomyśl dwa razy!). Dla typu całkowitego, który jest w stanie przedstawić różnicę między dwoma wskaźnikami, użyj ptrdiff_t. W przypadku rozmiarów obiektów użyj size_t.

Źródło

2012-10-09 07:55:32 janneb

Jeśli biblioteki wykonawcze są statycznie połączone, ABI nie powinno przejmować się tym, który typ kompilator wywołuje "long", pod warunkiem, że wszystkie zewnętrzne prototypy biblioteki są zdefiniowane przy użyciu typów o stałej szerokości, a kompilator nie próbuje denerwować rzeczy z aliasowaniem typów, które mają tę samą reprezentację, ale nie pasują do siebie. – supercat

-m32 generuje kod 32-bitowy.

-mx32 generuje 64-bitowy kod, ale używa 32-bitowych długości i wskaźników.

Intel 386 and AMD x86-64 Options

Źródło

2012-10-09 07:22:00

Ale jak by to interakcji z bibliotekami systemu przy użyciu 64 bitowych długości? – johv

Oryginalny plakat wydaje się wymagać, aby longs miał 32 bity, więc muszą one łączyć się z bibliotekami, które działają z 32-bitowymi danymi. Myślę, że gdy wywoływana jest funkcja, gdy potrzebuje 32-bitowego parametru, nie ma znaczenia, jaki typ danych miał wywołujący, i nie obchodzi go, czy wywołujący jest funkcją C. Ale tak, wywołujący musi upewnić się, że nie wywoła biblioteki, która oczekuje wartości 64-bitowych. –

@johv: Nie będzie. Używając -m32, musisz używać bibliotek ze "zwykłym" 32-bitowym ABI AB86, z -mx32 potrzebujesz bibliotek X32. – janneb

Tworzenie "długich" 4 bajtów w gcc na 64-bitowym komputerze z Linuksem

Odpowiedz

Powiązane problemy