Преобразование 32-разрядного приложения в 64-разрядное приложение в C

Просто пытался написать что-то более простое.

#!/usr/bin/python

from subprocess import Popen, PIPE
import datetime
import time 

popen = Popen(["/bin/sleep", "10"]);
pid = popen.pid
sttime = time.time();
waittime =  3

print "Start time %s"%(sttime)

while True:
    popen.poll();
    time.sleep(1)
    rcode = popen.returncode
    now = time.time();
    if [ rcode is None ]  and  [ now > (sttime + waittime) ] :
        print "Killing it now"
        popen.kill()
20
задан Charles Beaudoin 4 January 2009 в 22:21
поделиться

9 ответов

  1. Узнают, кто записал это. Действительно ли они - идиот? Они Вы от несколько лет назад? Можно ли задать им вопросы? Действительно ли они знакомы с существованием нескольких платформ и систем? При знании мышление автора (авторов) программы поможет Вам понять проблемы при столкновении с ними.
  2. Будят 64-разрядную машину/среду сборки и выполнение.
  3. Замена долго интервалом совершенно знать, что LONG не long.
  4. Замена (int)&x броски и вводящий с intptr_t и (unsigned int)&x с uintptr_t
  5. Аудит что-либо, что полагается на кастинг структур к char*, чтобы сделать адресную арифметику с указателями с ним.
  6. Regex ищут \< 4 \> в случае, если Вы приняли 4 = sizeof(void*)
  7. Быть терпеливыми. При нахождении проблемы посмотрите в другом месте, если та же проблема существует, и перенесите решение в макрос.
  8. Попытка не использовать #ifdef RUN64 или что-либо подобное. Вы будете сожалеть о нем, если 128-разрядные платформы когда-нибудь войдут в моду.
  9. Инкапсулируют все Ваши изменения с точки зрения некоторых централизованных макросов, это скроет различия в мобильности в другом месте в Вашей программе.
  10. Использование тестер покрытия, чтобы помочь удостовериться Вы покрыли все (если соответствующий)

, РЕДАКТИРОВАНИЕ добавило uintptr_t примечание, как предложено комментарием.

27
ответ дан 29 November 2019 в 23:02
поделиться

Одна потенциальная проблема, не уже упомянутая, состоит в том, что, если Ваши чтения приложения или пишет двоичные данные из диска (например, считайте массив структур с помощью fread), Вы оказываетесь перед необходимостью проверять очень тщательно и возможно завершать наличие двух читателей: один для файлов прежней версии и один для 64-разрядных файлов. Или, если Вы стараетесь использовать типы как uint32_t и так далее от <stdint.h> заголовочный файл, можно переопределить структуры, чтобы быть поразрядно совместимыми. В любом случае двоичный ввод-вывод является вещью не упустить.

8
ответ дан 29 November 2019 в 23:02
поделиться

Если бы Вы использовали корректные типы для своих значений - например, size_t, ptrdiff_t, uintptr_t, фиксированные размерные международные типы от stdint.h в соответствующих случаях - и не сделали размеров значения hardcode, то Ваш код должен работать из поля.

4
ответ дан 29 November 2019 в 23:02
поделиться

Это действительно зависит от приложения и как оно было кодировано. Некоторый код может просто быть перекомпилирован с 64-разрядным компилятором, и он будет просто работать, но обычно это только происходит, если код был разработан с мобильностью в памяти.

, Если код имеет много предположений о размере собственных типов и указателей, если он имеет много взломов упаковки бита или его, говорит с внешним процессом с помощью указанного протокола байта, но с помощью некоторых предположений о размере собственных типов затем он может потребовать, чтобы некоторые, или много, работы получили чистую компиляцию.

В значительной степени каждый бросок и предупреждение компилятора являются красным флагом, которому нужна проверка. Если код "не предупреждал чистый" для запуска с затем этого - также знак, что большая работа может требоваться.

5
ответ дан 29 November 2019 в 23:02
поделиться

Основная проблема, с которой Вы сталкиваетесь при переключении на 64 бита, состоит в том, что размер указателей отличается (64 бита вместо 32 - понятное дело), размер целых чисел и размер longs могли бы отличаться также, в зависимости от платформы.

, Почему это - проблема? Ну, это не, если Ваш код не предполагает, что sizeof (интервал) == sizeof (освобождают*). Это могло привести к противным ошибкам указателя.

3
ответ дан 29 November 2019 в 23:02
поделиться

Ну, существенно, количество изменений являются довольно маленькими, но это все еще будет главная задача, если приложение не будет тщательно записано, чтобы быть несколько портативным для начала.

основное различие - то, что указатели 64 бита шириной, , но большинство других типов данных неизменно. Интервал - все еще 32 бита, и длинными являются, вероятно, также все еще 32 бита. Таким образом, если Ваш код бросает между ints и указателями, это собирается повредиться. Точно так же любая структура или подобный, который зависит от определенного смещения участнику, может повредиться, потому что другие участники могут теперь быть более крупными, и так измените смещение.

, Конечно, Ваш код никогда не должен полагаться на эти приемы во-первых, таким образом, в идеальном мире, это не было бы проблемой вообще, и Вы могли просто перекомпилировать, и все будет работать. Но Вы, вероятно, не живете в идеальном мире... ;)

3
ответ дан 29 November 2019 в 23:02
поделиться

Этими двумя существенными различиями между 32-разрядным и 64-разрядным программированием в C является sizeof (пусто*) и sizeof (долго). Основная проблема, которую Вы будете иметь, состоит в том, что большинство систем Unix использует стандарт I32LP64, который определяет длинное как 64 бита, и Win64 использует стандарт IL32LLP64, который определяет длинное как 32 бита. Если необходимо поддерживать межплатформенную компиляцию, можно хотеть использовать ряд основанных на архитектуре определений типов для 32-разрядных и 64-разрядных целых чисел, чтобы гарантировать, что весь код будет последовательно вести себя. Это обеспечивается как часть stdint.h как часть стандарта C99. Если Вы не используете компилятор C99, Вам, возможно, понадобится к самокрутке, эквивалентной

, Как отмечено в другом месте, первоочередными задачами для преобразования будет код, которые предполагают, что sizeof (интервал) == sizeof (долго) == sizeof (пусто*), код поддерживает данные, которые были записаны в диск и код для кросс-платформенного IPC.

Для хорошего обзора истории позади этого, смотрите на этот статья от Очереди ACM.

2
ответ дан 29 November 2019 в 23:02
поделиться

Уже существует много хороших ответов.

Рассматривают использование Линт Gimpel . Это может указать точно на типы конструкций, которые проблематичны. Если Ваш опыт будет похож на мой, то он также покажет Вам много ошибок в системе, не связанной с портом на 32/64 бита.

2
ответ дан 29 November 2019 в 23:02
поделиться

Все о 64-битной архитектуре для разработчиков:

Статьи о 64-битной разработке

Ссылки collection 64-разрядные ресурсы

Инструмент Viva64

2
ответ дан 29 November 2019 в 23:02
поделиться
Другие вопросы по тегам:

Похожие вопросы: