Вызов RPC возвращает возрастающее значение вместо ULONG_PTR

Я относительно новичок в коде RPC, поэтому приношу свои извинения, если это тривиально.

Я пишу функцию RPC, которая вызывает функцию WINAPI в WinSCard на стороне сервера. Функция, SCardEstablishContext, возвращает дескриптор LPSCARDCONTEXT по ссылке, который в конечном итоге является просто ULONG_PTR, который является беззнаковым указателем __int64. В идеале серверный вызов RPC должен затем передать это значение дескриптора клиенту, который сделал вызов

Моя проблема в том, что, когда я делаю это, вместо того, чтобы получить значение без знака __int64, помещенное в местоположение, на которое ссылается указатель, который я передал в функцию RPC, я вместо этого получаю одну цифру, начиная с 0, которая просто увеличивается, если мы делаем последующие вызовы к функции RPC.

Если я исключу вызов функции WINAPI, я могу без проблем передать и установить значения ULONG_PTR / unsigned __int64, поэтому я понятия не имею, почему вместо этого я получаю увеличенную цифру на стороне клиента.

Код на стороне клиента

ULONG_PTR myuptr = 0;
ULONG_PTR* cpr = &myuptr;
TC_LongRetVal(cpr);
cout << "My ULONG_PTR's value is: " << *cpr << "\n";

Серверный код

int TC_LongRetVal(ULONG_PTR* b){
LPSCARDCONTEXT contH = b;
SCardEstablishContext(2, NULL, NULL, contH);
return 0 ;
}

Определение интерфейса

int TC_LongRetVal([in, out] ULONG_PTR* b);

Если я отлаживаю эту функцию и прохожу через вызовы на стороне сервера, непосредственно перед возвратом значения LPSCARDCONTEXT «contH» и указателя аргумента «b» идентичны. Но в этом случае после возврата вместо «cpr» на клиенте, указывающем на значение «14771806 …… 185», он указывает на ULONG_PTR со значением «0» при первом вызове. Если я перезапущу код клиента, значение CPR увеличивается на 1 с каждым последующим вызовом, пока я не перезапущу сервер RPC.

введите описание изображения здесь

Есть ли причина, по которой я не могу вернуть реальное значение ULONG_PTR? Почему значение указателя увеличивается на единицу? Я знаю, что этот дескриптор ничего не значит для клиента, но я собираюсь использовать его в последующих обращениях к серверу.

Обновление 1
Я обновил код на стороне сервера, чтобы посмотреть, смогу ли я получить какие-либо значения, которые были явно установлены. После некоторой игры вокруг и ощущения, что часть «64» в «unsigned __int64» как-то связана с этим, я, наконец, обнаружил, что если я вернусь обратно к 4294967295, наибольшему 32-битному значению без знака или к чему-то меньшему, функция работает отлично. Отправка обратно 4294967296, однако, возвращает 0, а ..97 возвращает 1 и т. Д.

Похоже, что проблема с моим кодом RPC, обрабатывающим 64-битные значения.

1

Решение

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

В файле определений IDL я был вынужден объявить свои собственные определения типов, поскольку IDL поддерживает только базовые типы. Когда я определил ULONG_PTR, я набрал его в __int3264, который будет изменяться между 32-битным или 64-битным в зависимости от системы. В то время как обе системы, которые я тестировал, были 64-битными, __int3264 усекаются до 32-битных перед отправкой по проводам.

Смена типа интерфейса для ULONG_PTR на __int64 сделала свое дело.

0

Другие решения


По вопросам рекламы [email protected]