Добрый день.

Суть:
-есть DLL, написанная на С, Visual Studio (номер точно не знаю, уточнить можно);
-DLL статически связана с проектом на Delphi;
-вызывается функция Decoder(idx:ULONG; pInp_burst, pOut_frame:pointer; pConfigDecoder:PDecoderStruct):HRESULT;stdcall;
-все параметры функции — локальные переменные в процедуре;
-вызов функции "портит" некоторые поля структуры PDecoderStruct но не всегда!!!
-вернее будет сказать так:
-я отслеживаю 6-8 первых полей структуры, назовем их A1..A8 (ULONG);
-при неком определенном значении указателя стека эти поля не искажаются в результате вызова функции Decoder;
-если я добавляю перед вызовом функции Decoder несколько push-ей — то какое-то из полей A1...A8 будет испорчено, т.е. конструкция
...
rez :=Decoder(...);

отрабатывает нормально (при неком значении ESP для начала функции) а конструкция

asm
push eax;
push eax;
push eax;
...
push eax;
end;
rez :=Decoder(...);

приводит к "порче" полей структуры.

— количество push-ей зависит от контекста вызова функции, т.е. от размеров, или положения, или (еще чего-то) локального стека функции.
— возможно (и скорее всего), для первой конструкции искажения тоже присутствуют, но они попадают в поля структуры, в которых их отследить сложнее.

Я считаю, что в реализации функции Decoder(...) есть какая-то ошибка но я не могу найти объяснение такому её поведению, соответственно,
не понятно-как её локализовывать разработчику DLL: другая среда, другие значения стека.... и т.д.

Собственно-вопрос: что может теоретически в реализации функции Decoder(...) (или в её использовании мною) приводить к такомe эффекту?
Неициализированная переменная в DLL, которая "попадает" на разный адрес (при сдвижке стека), а там-какой-то "мусор", который интерпретируется соответственно?
Была такая мысль, но не подтверждается: если, к примеру, нужно добавить 5 push-ей, чтобы начал портится поле A8, то при 6 push-ах — портится поле А7,
7 push-А6 и т.д.

Всем спасибо заранее

PS: Размерность и тип входных параметров функции проверили.

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

RSD>Добрый день.

А Вы уверены, что

Decoder(idx:ULONG; pInp_burst, pOut_frame:pointer; pConfigDecoder:PDecoderStruct):HRESULT;stdcall;

действительно "stdcall" ?

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

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

RSD>>Добрый день.

B>А Вы уверены, что
B>

B>Decoder(idx:ULONG; pInp_burst, pOut_frame:pointer; pConfigDecoder:PDecoderStruct):HRESULT;stdcall;
B>

B>действительно "stdcall" ?

К сожалению-уверен, так как есть h-файл к DLL:
#define DECODER_API __declspec(dllexport) HRESULT __stdcall
#else
#define DECODER_API extern "C" __declspec(dllimport) HRESULT __stdcall
...
DECODER_API Decoder(ULONG idx, unsigned char* inp_burst, unsigned char* out_frame, DECODER_CONFIG_RECORD* pConfigDecoder);

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

B>>А Вы уверены, что
B>>

B>>Decoder(idx:ULONG; pInp_burst, pOut_frame:pointer; pConfigDecoder:PDecoderStruct):HRESULT;stdcall;
B>>

B>>действительно "stdcall" ?

RSD>К сожалению-уверен, так как есть h-файл к DLL:
RSD>#define DECODER_API __declspec(dllexport) HRESULT __stdcall
RSD>#else
RSD>#define DECODER_API extern "C" __declspec(dllimport) HRESULT __stdcall
RSD>...
RSD>DECODER_API Decoder(ULONG idx, unsigned char* inp_burst, unsigned char* out_frame, DECODER_CONFIG_RECORD* pConfigDecoder);

А вот само поведение напоминает глюки, связанные с вызовом cdecl функции как stdcall

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

DM>Здравствуйте, flashRSDN, Вы писали:
DM>А вот само поведение напоминает глюки, связанные с вызовом cdecl функции как stdcall

Я бы так не сказал: тогда бы стек бы был неверным с более глобальными последствиями
PS: В DLL обнаружилась ошибка: запись в памяти за границы массива, но почему она так проявляла себя для меня остается Загадкой.