returning char *

[Perky]

I'm having a problem executing a command in a .dll.  I created a header file and .dll import library and 6 of the 7 functions are executing as they should.  However, the 7th function returns a character string, which I prototype as char *, as per the information I've been supplied with.  When I call the function the application gives a GPF. 

basically this is what I have

.dll .h file

char * GetReturn(void);

Function

void random(void)

{

 char * szRetv;

 szRetv = malloc(100);
 szRetv = GetData();
 free(szRetv);

}

I've also tried without malloc, even tired as a char szRetv[200] and tried changing the variable type to int just to make sure there's nothing wrong with the prototype.

The .dll I'm calling was written in Microsoft C++, so I assume it's using the string class for the data.  If this is the case, is there anything specific I need to do to handle it?  I've not seen this problem before. 

[jr_2005]

There is a problem with your code; first you malloc() some memory and set your pointer szRetv to it, but then you re-set the value of the pointer with a call into GetData(). So when you call free(), the pointer no longer points to the area reserved by malloc() and the inevitable result is a problem. Perhaps what you need is something along these lines:

    char * szRetv;

    szRetv = malloc(100);        // Space for the string
    strcpy (szRetv, GetData());  // Returned value is a pointer, so it can be copied from

                                 // Do stuff with the string
    free (szRetv);               // Finished

This will make a working copy of the returned string pointer.

JR

[Perky]

Unfortunately the suggestion didn't make any difference 😞  Because of the crash when calling the GetData function, the code never reaches the free() command.

Previously I also tried this way :

InsertTextBoxLine (panelHandle, PANEL_txtWinMSG, -1, GetData());

Oh and there's a typo in my first message, the prototype should be named GetData.

[jr_2005]

What about the calling conventions? A few years back we had a similar situation when someone devloped a dll for us - most of the routines worked but when we investigated why some didn't we discovered that they had used the wrong calling convention. Could be worth double-checking whether the dll (and hence the header file) requires a _cdecl or _stdcall prefix to the prototypes.

JR

[Perky]

there are 7 callable functions in the .dll, 6 of which work without issue. 

If I try to use __cdecl as the calling convention then I get link errors for the functions (undefined symbols), but they link ok with __stdcall. 

The GPF is still consistently crashing the app even with __stdcall.

By the way thanks for the help on this.

[jr_2005]

I've not been much help so far

Is the dll a commercial offering? Do you know if it has been used successfully elsewhere? Can you contact its suppliers/writers for help and/or more information - for example what is the maximum size of string that can be returned. On second thoughts that can't be your problem, if the crash occurs inside the dll function. Presumably the CVI debugger can shed no light on this, either.

Returning a pointer can be problematic with careless programming; I have seen cases where a local pointer has been created, manipulated and then returned from a function - the author having forgotten that at this point the local pointer (allocated on the stack of the function) becomes garbage. I would expect that a properly written and tested library would take pains to ensure that this could not happen.

I'm fast running out of suggestions - anyone else got some ideas?

JR