Мы занимаемся вопросами разработки и тестирования 64-битных приложений. Недавно мы написали новую статью: 20 issues of porting C++ code on the 64-bit platform.

Аннотация. Рассмотрены программные ошибки, проявляющие себя при переносе Си++ — кода с 32-битных платформ на 64-битные платформы. Приведены примеры некорректного кода и способы его исправления. Перечислены методики и средства анализа кода, позволяющие диагностировать обсуждаемые ошибки.

Текст статьи на английском языке (PDF)

Мы будем рады получить ваши отзывы, замечания, поправки, дополнения, которые будут внесены следующие версии статьи.
----
Viva64 team, www.Viva64.com

Здравствуйте, Analytic2007, Вы писали:

A>Мы занимаемся вопросами разработки и тестирования 64-битных приложений. Недавно мы написали новую статью: 20 issues of porting C++ code on the 64-bit platform.

Пролистал половину, остальное вечером дочитаю. Статья вроде дельная. Спасибо за работу.

Одну ошибочку заметил.
1. Off-warnings

unsigned char *array[50];
unsigned char size = sizeof(array);
32-bit system: sizeof(array) = 200
32-bit system: sizeof(array) = 400

A>Мы занимаемся вопросами разработки и тестирования 64-битных приложений. Недавно мы написали новую статью: 20 issues of porting C++ code on the 64-bit platform.

Мне кажется, что эта статья опоздала примерно на год.

P.S.
Ничего полезного не обнаружил.

Здравствуйте, MShura, Вы писали:

A>>Мы занимаемся вопросами разработки и тестирования 64-битных приложений. Недавно мы написали новую статью: 20 issues of porting C++ code on the 64-bit platform.

MS>Мне кажется, что эта статья опоздала примерно на год.

В смысле?
Уже все системы перенесли на 64-битную архитектуру?

MS>>Мне кажется, что эта статья опоздала примерно на год.

А>В смысле?
А>Уже все системы перенесли на 64-битную архитектуру?

По моему мнению компании, для которых поддержка 64 битных платформ очень важна сделали/начали перенос кода более года назад.

Здравствуйте, Analytic2007, Вы писали:

<>

8. Change of an array type

int array[4] = { 1, 2, 3, 4 };
enum ENumbers { ZERO, ONE, TWO, THREE, FOUR };
//safe cast
ENumbers *enumPtr = (ENumbers *)(array);

Где здесь safe cast? sizeof(ENumbers) <= sizeof(int), это платформенно-зависимо. Если компилятор захочет, он запихает его в 1 байт, и всё поплывёт ровно так же, как поплыло с 8-байтным size_t в //unsafe cast

Здравствуйте, korzhik, Вы писали:
K>Одну ошибочку заметил.
K>1. Off-warnings
K>unsigned char *array[50];
K>unsigned char size = sizeof(array);
K>32-bit system: sizeof(array) = 200
K>32-bit system: sizeof(array) = 400
Спасибо. Исправим.

Здравствуйте, Кодт, Вы писали:

К>8. Change of an array type
К>

К>int array[4] = { 1, 2, 3, 4 };
К>enum ENumbers { ZERO, ONE, TWO, THREE, FOUR };
К>//safe cast
К>ENumbers *enumPtr = (ENumbers *)(array);
К>

К>Где здесь safe cast? sizeof(ENumbers) <= sizeof(int), это платформенно-зависимо. Если компилятор захочет, он запихает его в 1 байт, и всё поплывёт ровно так же, как поплыло с 8-байтным size_t в //unsafe cast

Согласен с замечанием. Схалтурил.

p.s.
Прошу продолжать.

A>Мы будем рады получить ваши отзывы, замечания, поправки, дополнения, которые будут внесены следующие версии статьи.
A>Viva64 team, www.Viva64.com

Спасибо

Здравствуйте, Analytic2007, Вы писали:

A>Мы занимаемся вопросами разработки и тестирования 64-битных приложений. Недавно мы написали новую статью: 20 issues of porting C++ code on the 64-bit platform.


Что за бред товарищи ?

time_t — 64 bit на 32-битной тоже. Вы с миграцией на VS8 попутали

A>Мы будем рады получить ваши отзывы, замечания, поправки, дополнения, которые будут внесены следующие версии статьи.
A>----
A>Viva64 team, www.Viva64.com


сходу не увидел про работу с файлами и off_t и f_pos.
имхо надо бы добавить

Здравствуйте, Analytic2007, Вы писали:

A>Мы будем рады получить ваши отзывы, замечания, поправки, дополнения, которые будут внесены следующие версии статьи.

Английский язык корявый.

Здравствуйте, Analytic2007, Вы писали:

A>Текст статьи на английском языке (PDF)

А на русском будет версия?

Здравствуйте, avbochagov, Вы писали:

A>А на русском будет версия?

http://www.viva64.com/articles/rus/20%20issues%20of%20porting%20C++%20code%20on%20the%2064-bit%20platform%20(rus).pdf

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

После чего в своем коде используются не стандартные int, long и т д... а свои введенные, аля
INT8, INT16, INT24, INT32, INT64, а так же размеры адресного пространства и многие другие вещи.

После чего имеем код, который компилится под любую платформу и прекрасно там работает =)

Здравствуйте, korzhik, Вы писали:

K>1. Off-warnings

K>unsigned char *array[50];
K>unsigned char size = sizeof(array);
K>32-bit system: sizeof(array) = 200
K>64-bit system: sizeof(array) = 400

А в чем ловушка-то? Только в том что 400 не лезет в unsigned char? Ну так это проблема не 64-битных платформ.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, korzhik, Вы писали:

K>>1. Off-warnings

K>>unsigned char *array[50];
K>>unsigned char size = sizeof(array);
K>>32-bit system: sizeof(array) = 200
K>>64-bit system: sizeof(array) = 400

А>А в чем ловушка-то? Только в том что 400 не лезет в unsigned char?

ну да

Здравствуйте, korzhik, Вы писали:

K>>>1. Off-warnings

K>>>unsigned char *array[50];
K>>>unsigned char size = sizeof(array);
K>>>32-bit system: sizeof(array) = 200
K>>>64-bit system: sizeof(array) = 400

А>>А в чем ловушка-то? Только в том что 400 не лезет в unsigned char?

K>ну да

Ну так это проблема не 64-битных систем, а кривости рук разработчика. Если ему придется заменить на char *array[100] возникнет точно такая проблема.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, korzhik, Вы писали:

K>>>>1. Off-warnings

K>>>>unsigned char *array[50];
K>>>>unsigned char size = sizeof(array);
K>>>>32-bit system: sizeof(array) = 200
K>>>>64-bit system: sizeof(array) = 400

А>>>А в чем ловушка-то? Только в том что 400 не лезет в unsigned char?

K>>ну да

А>Ну так это проблема не 64-битных систем, а кривости рук разработчика. Если ему придется заменить на char *array[100] возникнет точно такая проблема.

ну да

Здравствуйте, Analytic2007, Вы писали:
A>Текст статьи на английском языке (PDF)
A>Мы будем рады получить ваши отзывы, замечания, поправки, дополнения, которые будут внесены следующие версии статьи.

-1. Что у вас с кернингом? В evince под линуксом (движок xpdf) буквы просто наезжают друг на друга, в acrobat reader'е под виндой эффект меньше, но все равно есть.

0. Английский язык, мягко говоря, стремный. Например "capable to keep" --> "capable of keeping" и многое другое, русскоязычное построение предложений просто выпирает.

Далее по разделам.

1. Off-warnings. Ну опять английский... "WTF!", подумал я, переведя это дело как "внешне-предупреждения" Я бы вообще сделал заголовки в активной форме, т.е. не что неправильно, а как поступить чтобы было правильно. В частности, название этого раздела написал бы в виде "Enable full warnings for the whole project". Ну и то что это проблема кривых рук вообще (увеличение массива в два раза тоже приведет к проблемам) тут уже написали.

2. Это не проблема функций с переменным числом аргументов. Функция int sum_int(unsigned count,...); от этого не страдает. Это проблема функций с c-style форматными строками.

3. Я бы разделил на два раздела. Одно дело магические числа, когда предполагается что размер указателя 4 байта, а другое -- когда константы без явного указания размера предполагаются имеющими тип int.

4. Дас ист фантастиш. Программиста, который так делает (на любой платформе) надо засушить и выставить в музее, в назидание остальным. Ну или хотя бы не подпускать к плавучке.

8. Ну то что размер enum'а не обязан совпадать с размером int'а тут уже сказали. За это надо программиста бить по рукам независимо от платформы.

12. Тоже в общем-то проблема непонимания целочисленной арифметики в C, а не

17. См. комментарий внизу. Впечатление притянутости за уши. Рассматриваемый дизайн вообще сам по себе стремный, это аккуратно подложенные грабли независимо от платформы.

19. То же самое, садизм какой-то. Эти грабли должны были быть найдены гораздо раньше портирования, например если бы кто-то завел привычку кидаться не только int'ами, но еще и скажем long long

Почему я вообще делал комментарии вида "За это надо программиста бить по рукам" -- это потому, что если быть до конца последовательными в этом вопросе, надо перечислять вообще ВСЕ ошибки, совершаемые неопытными программистами В противном случае это производит впечатление притягивания за уши, чисто для объема статьи.