Заметил знакомый топик :)

18-я весна
...- некорректны (должен быть тип ulong и long в обеих ф-ях)
Так что если этот пример работает (в чем я сомневаюсь), то вы поистине везучий человек :)


Ну да , повезло. Хотя ... Есть "тайные знания"

Все приличные компиляторы, оформляя вызов функции через стек, производят выравнивание данных по стандартному размеру регистра стека.
Для P5 - это 32 разряда - 4 байта - т.е. long в определениях PowerBuilder

поэтому обявлению
funname(long a, int b, *char c)
эквивалентно по размещению в стеке (но не ограничению на допустимые значения) обьявлению
funname(long a, long b, *char c)

в обоих случаях переменная b будет смещена от вершины стека на одну единицу адресного пространства - т.е. физически смещена на 4 байта. 2-х байтные integer 32-разрядный процессор просто не в состоянии адресовать - что типа (0h45dc99 + 1/2)

А вот пара integer (важно - передаваемых по значению а не ссылке) - параметра подряд буду упакованы в один long.


Вообще-то 16-разрядный int в 32-разрядной архитектуре по-хорошему надо было бы задвинуть давно. Дык - совместимость... И об этих мелких граблях приходится помнить.

Sorry - собственно забыл добавить в предыдущий пост главный point .

Все эти багоглюки с 8-16 разрядным (а в перспективе 32-64) представлением одних и тех же обьектов подарят нам еще немало "открытий чудных"

Для начала. Выяснилась непереносимость старых приложений PB9 -> PB11 из-за того, что простенькая функция Blob(string s) работает по-разному. Оказывается в PB11 по умолчанию она работает в utf16.