pin_ptr um vazio nativo* ajuda

Question

A configuração

Eu tenho uma API PDF que possui uma função nativa definida abaixo.

typdef void* PDF_DOCUMENT;
unsigned long PDF_GetMetaText(PDF_DOCUMENT document,
                              const char tag, 
                              void* buffer, 
                              unsigned long bufferlen)

//Calling it "natively" in C++/CLI function to get the PDF Creator tag
WCHAR result[32];
void* pdoc = PDF_LoadDoc("C:\test.pdf");
int numChars = PDF_GetMetaText(pdoc, "Creator", result, 32);
PDF_CloseDoc(pdoc);

Se eu ligar para o código acima na minha função de wrapper C ++/CLI, ele retornará a sequência correta, mas lança um AccessViolationException quando eu ligo para PDF_CLOUSDOC. Woops. Esqueci de pin_ptr o ponteiro do documento.

O problema

Quando eu pin_ptr pdoc, posso chamar com sucesso essas funções nativas, no entanto, o buffer não contém mais minha string quando PDF_GetMetatext retorna.

String^ Wrapper::GetCreator(String^ filename)
{
   WCHAR buffer[32];
   void *pdoc = PDF_LoadDoc(SystemStringToCStr(filename));
   pin_ptr<void*> p = &pdoc; //added
   int numPages = PDF_GetMetaText(p, "Creator", buffer, 32);
   PDF_CloseDocument(p); //doesnt crash, but at this line buffer is an empty string

   return gcnew String(buffer);
}

Eu também tentei fixar o buffer [0], mas isso causa uma exceção de acesso ao getMetatext.

A questão

Não posso dizer o que está acontecendo no getMetatext, então não tenho certeza do que está acontecendo com o PDOC. Alguma sugestão para o código acima?

Answer 1

Isso não faz sentido. Você só pode fixar objetos gerenciados, o valor de retorno de pdf_loaddoc () com certeza não parece um objeto gerenciado para mim. O mesmo vale para resultado, não é um gerenciado array<WCHAR>, apenas uma matriz simples de baunilha C que é alocada no quadro da pilha. Infelizmente, Pin_Ptr <> não reclama disso.

o resultado A matriz só poderia ficar 'vazia' se o código estiver pisando no quadro da pilha. Que você pode diagnosticar definindo um ponto de interrupção de dados no primeiro elemento. FWIW, SystemStringTocstr () parece um candidato. Isso não pode funcionar sem liberar o buffer para a sequência nativa em algum lugar. Outro candidato são as declarações da função da API em PDF. Preste atenção ao valor do registro ESP e verifique se ele não muda. Se isso acontecer, a pilha fica desequilibrada porque você não tem a convenção de chamada adequada. Que geralmente é __stdCall para exportações de DLL.