Как влияет Range check на работу результирующего кода?

← →
@!!ex © (2011-05-05 16:22) [40]

Добавилось 4 строки:
0045985D 8B4DE8 mov ecx,[ebp-$18]
00459860 85C9 test ecx,ecx
00459862 7905 jns $00459869
00459864 E863A0FAFF call @BoundErr

BoundErr не вызывается ни разу. То есть сам эксцепшн не возникает. Именно сопутствующий код как-то влияют.

← →
@!!ex © (2011-05-05 16:23) [41]

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

← →
@!!ex © (2011-05-05 18:32) [42]

Вынес вычисление указателя в отдельную строчку - все заработало как надо:
It:=Pointer(cardinal(Data)+size-bytes); CopyMemory(It,@Buffer[0],bytes);

← →
Sha © (2011-05-05 20:20) [43]

Ни разу не замечал, чтобы RangeCheck изменял
распределение регистров или переменных на стеке.
Но вдруг у тебя это не так.
Проверь свой исходный вариант на всякий случай.
Если окажется, что что-то меняется (стек или регистры),
то ov_read, возможно, это что-то портит.

И еще раз спрошу как ты узнал, что приведенный код
меняет свое поведение? А не ov_read?

← →
Sha © (2011-05-05 20:47) [44]

> @!!ex
Если используешь Delphi 7, приведи здесь минимальный компилируемый без ошибок кусок кода.

← →
Sha © (2011-05-05 20:58) [45]

> @!!ex
tell_func должна возвращать integer или int64?

← →
@!!ex © (2011-05-05 21:47) [46]

> Если окажется, что что-то меняется (стек или регистры),
>
> то ov_read, возможно, это что-то портит.

Вроде бы не меняется.

> И еще раз спрошу как ты узнал, что приведенный код
> меняет свое поведение? А не ov_read?

Проверял Buffer который возвращает ov_read, вроде он одинаковый всегда.
Да и с чего бы ему менять свое поведение, он же в отдельной dll!

> [44] Sha © (05.05.11 20:47)
> Если используешь Delphi 7, приведи здесь минимальный компилируемый
> без ошибок кусок кода.

У меня Turbo Delphi 2006

> [45] Sha © (05.05.11 20:58)
> tell_func должна возвращать integer или int64?

long в C++ хедере. То есть дельфевый integer.

Вроде бы проблем аразрешилась вынесением расчета указателя в отдельную строку.
Видимо глюк компилятора? вероятно не имеет смысла дальше копать проблему. Просто время потратим.

← →
Inovet © (2011-05-05 22:17) [47]

> [46] @!!ex © (05.05.11 21:47)
> Видимо глюк компилятора?

Ты же сказал, что ничего не менялось кроме

> [40] @!!ex © (05.05.11 16:22)
> Добавилось 4 строки:
> 0045985D 8B4DE8 mov ecx,[ebp-$18]
> 00459860 85C9 test ecx,ecx
> 00459862 7905 jns $00459869
> 00459864 E863A0FAFF call @BoundErr

Глюка не видать.

← →
Sha © (2011-05-05 22:23) [48]

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

Не разрешилась, а скорее всего упрятана еще глубже.

> Видимо глюк компилятора?

Видишь глюк в сгенерированном коде - покажи,
не видишь - не надо напраслины.
Какой может быть глюк, если распределение переменных
по регистрам и стеку то же самое?
Их порча в ov_read куда вероятнее.

> вероятно не имеет смысла дальше копать проблему. Просто время потратим.

Ну, тогда кидай батоны. А код все же приведи, будет время - гляну.

← →
han_malign (2011-05-06 10:10) [49]

> Вынес вычисление указателя в отдельную строчку - все заработало как надо:
> It:=Pointer(cardinal(Data)+size-bytes);
> CopyMemory(It,@Buffer[0],bytes);

- вот и проверь какой какой asm код генерируется в исходном и этом случае(*$R-*), раз место локализовано...

З.Ы. В отличие от D7, BDS уже не ругается на "signed/unsigned mismatch", а молча расширяет до int64(напоролся тут недавно...), возможно $R+/- меняет это поведение.
С короткой формой записи у D2k6(Express) проблемы(например Obj.MethodReturnedObj.Method - вываливается на этапе компиляции), так что это действительно может быть фичей глюкогенератора...

← →
@!!ex © (2011-05-08 15:50) [50]

> А код все же приведи, будет время - гляну.

Я привел весь код загрузки OGG.
Выложить еще дополнительно всю инициализацию OpenAL, инициализацию Sound Buffer"a под полученные из OGG данные и создание Sound Source для воспризведения?

← →
Мимо хотел пройти (2011-05-08 18:42) [51]

> @!!ex © (08.05.11 15:50) [50]

Да, выложи пожалуйста.

> @!!ex © (08.05.11 15:50) [50]
> Я привел весь код загрузки OGG.

Ты пробовал компилировать, то что привел?

> Выложить еще дополнительно ... ?

Да мне пофиг.

> Ты пробовал компилировать, то что привел?

Конечно. А в чем проблема?

> А в чем проблема?

Твоя проблема в том, что ты не слышишь других.

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

Этот код 1 в 1 повторяет код проекта на котором я проводил тесты, он тупо отткуда скопипастен.
Так что мне все еще не понятно в чем ваша проблема с компиляцией этого кода.

Наверно, в том, что я тоже ленив
и наперед знаю, что ни такой код

unit RangeCheckFormP; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs; type TForm1 = class(TForm) private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation {$R *.dfm} // тут твой код из [18] end.

ни такой

program RangeCheckConsole; {$APPTYPE CONSOLE} uses SysUtils; // тут твой код из [18] begin { TODO -oUser -cConsole Main : Insert code here } end.

даже не скомпилируется.

Как влияет Range check на работу результирующего кода? Найти похожие ветки