pin_ptr una ayuda native void *

Question

El programa de instalación

Tengo un API de PDF que tiene una función nativa que se define a continuación.

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);

si llamo el código anterior en mi función de contenedor C ++ / CLI, devuelve la cadena correcta, pero lanza una AccessViolationException cuando llamo PDF_CloseDoc. Woops. Se me olvidó pin_ptr el puntero del documento.

El problema

Cuando pin_ptr PDOC, puedo llamar con éxito estas funciones nativas, sin embargo, el búfer ya no contiene mi cadena cuando vuelve PDF_GetMetaText.

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);
}

También he intentado fijar búfer [0], sino que provoca una excepción en accessviolation GetMetaText.

La pregunta

no puedo decir lo que está sucediendo en GetMetaText, así que no estoy seguro de lo que se happing a PDOC. ¿Alguna sugerencia para el código anterior?

Answer 1

Esto no tiene ningún sentido. Sólo se puede fijar objetos gestionados, el valor de retorno de PDF_LoadDoc () seguro que no se ve como un objeto administrado a mí. Lo mismo va para resultado , no es un array<WCHAR> administrado, sólo un conjunto C con sabor de vainilla que consigue asignado en el marco de pila. Por desgracia, pin_ptr <> no se quejan de esto.

El resultado array sólo podía conseguir 'vacío' si el código está pisando el marco de pila. Que se puede diagnosticar mediante el establecimiento de un punto de interrupción de datos en el primer elemento. Fwiw, SystemStringToCStr () se parece a un candidato. Esto no puede funcionar sin soltar el tampón para la cadena en algún lugar de origen. Otro candidato es las declaraciones de funciones API PDF. Tenga en cuenta el valor del registro ESP y asegúrese de que no cambia. Si lo hace, la pila es conseguir desequilibrada, ya que no tiene la convención de llamada apropiada. Que suele ser __stdcall para las exportaciones DLL.