Мы занимаемся вопросами разработки и тестирования 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

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

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


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

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

Вот спасибо за оперативность и за статью

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

A>>А на русском будет версия?
A>http://www.viva64.com/articles/rus/20%20issues%20of%20porting%20C++%20code%20on%20the%2064-bit%20platform%20(rus).pdf
Интересная статья, хотя русский язык часто хромает, например:

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

6. Упаковка указателей
…
В конце хочется заметить, что плохим стилем будет упаковка указателя в типы всегда равные 64-битам. Показанный далее код вновь придётся исправлять с приходом 128-битных систем.

PVOID p;
// Bad style. The 128-bit time will come.
__int64 n = __int64(p);
p = PVOID(n);

А что, существуют 128-битные платформы? Хотя бы в планах?

Здравствуйте, 0x8000FFFF, Вы писали:
FFF>После чего в своем коде используются не стандартные int, long и т д... а свои введенные, аля
FFF>INT8, INT16, INT24, INT32, INT64, а так же размеры адресного пространства и многие другие вещи.
Int24 – это на каких платформах бывает?

ПС>А что, существуют 128-битные платформы? Хотя бы в планах?


PlayStation 2 computer entertainment system's Emotion Engine CPU is a 128-bit processor.

The AS/400 instruction set defines all pointers as 128-bit.

ПС>Здравствуйте, 0x8000FFFF, Вы писали:
FFF>>После чего в своем коде используются не стандартные int, long и т д... а свои введенные, аля
FFF>>INT8, INT16, INT24, INT32, INT64, а так же размеры адресного пространства и многие другие вещи.
ПС>Int24 – это на каких платформах бывает?


Еще ЕС-ки были 48-битные

Здравствуйте, Lepsik, Вы писали:
ПС>>А что, существуют 128-битные платформы? Хотя бы в планах?
L>PlayStation 2 computer entertainment system's Emotion Engine CPU is a 128-bit processor.
PlayStation 2 – это 32-битная платформа (там всего лишь 32 MB оперативной памяти). int и указатели там 32-битные.

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

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

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

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

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

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

Лично я с проблемами при работе с файлами не сталкивался. А, фантазировать не хочется. Буду благодарен Вам за пример подобных ошибок (связанных с off_t и f_pos).

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

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


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

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

A>Вот спасибо за оперативность и за статью

Ну, по поводу оперативности.... Статья на русском ужу готова была. При чем мы месяц назад хотели ее здесь на RSDN выложить. Написали письмо. В ответ уже месяц тишина.

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

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

ПС>А что, существуют 128-битные платформы? Хотя бы в планах?
Если и нет — то будут.

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

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

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

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

1) Мы сами пробовали такой подход и остались недовольны. Но спорить не буду.
Это отдельную статью писать надо.

2) То, что предлагается, к сожалению никак не может помочь при переносе УЖЕ существующего кода.

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

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

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

Знаем. Постараемся улучшить. Кто читает английский вариант — большая просьба присылать пометки (karpov@viva64 .dot. com). Будем очень благодарны.

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

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

Не обязательно. Можно и нечто новое придумать. Проблема функций с c-style форматными строками — просто самая распространенная.

Спасибо за замечания.

чтобы так безапеляционно завлять надо знать предмет уважаемый

http://arstechnica.com/cpu/1q99/playstation2-cpu.html

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

L>чтобы так безапеляционно завлять надо знать предмет уважаемый
L>http://arstechnica.com/cpu/1q99/playstation2-cpu.html
Там нет размеров int-а или указателя.

PATCH: 64 bit cleanups for Lua 5.1-work2:

Here is a table of the common data models that Lua supports:

Data model	short	int	long	long long	void*	size_t	ptrdiff_t	Platform examples
LP32	16	16	32	-	32	16	32	WIN16, MSDOS-large
ILP32	16	32	32	[64]	32	32	32	WIN32, Unix-32bit
L64	16	32	64	-	32	32	32	PS2
LP64	16	32	64	64	64	64	64	Unix-64bit
LLP64	16	32	32	64	64	64	64	WIN64
ILP64	16	64	64	64	64	64	64	(abandoned ~'95)

Поэтому с точки зрения C/C++-программиста PlayStation 2 – это 32-битная платформа. Оно и понятно: чтобы адресовать 32 MB оперативной памяти, 32-битного указателя вполне достаточно (а вот 128-битный указатель – это был бы перебор).