Call Library node with function returning C string

[RLD]

I have a DLL function with a function prototype of "char * StatusString( int status );". The Call Library node for it provides a LabVIEW string terminal in the upper right corner to which a string indicator can be wired. But if the function is passing back a null terminated C string does LabVIEW "magically" create the LabVIEW string data without additional programming by the developer? This would be for LabVIEW 6.1.

Rich

[Greg_McKaskle2]

> I have a DLL function with a function prototype of "char *
> StatusString( int status );". The Call Library node for it provides a
> LabVIEW string terminal in the upper right corner to which a string
> indicator can be wired. But if the function is passing back a null
> terminated C string does LabVIEW "magically" create the LabVIEW string
> data without additional programming by the developer? This would be
> for LabVIEW 6.1.
>

When the type is C string, LV will automatically turn a NULL string into
an empty LV string.

Greg McKaskle

[RLD]

Greg,

Can you amplify a bit more?

When a CLN is accessing a function which has a string pointer return type (as opposed to a pointer in the argument list), the CLN should be passing back a non-empty string. I'm hoping you mean that LV will automatically convert this C string to the equivalent LV string.

Rich

[Greg_McKaskle2]

> When a CLN is accessing a function which has a string pointer return
> type (as opposed to a pointer in the argument list), the CLN should be
> passing back a non-empty string. I'm hoping you mean that LV will
> automatically convert this C string to the equivalent LV string.
>

Yes, if LV allows you to cofigure the node with a pointer to a C style
string in either parameter or return value, LV will translate to and
from on the call.

In this specific case, LV has nothing to do on the call, but on the
return, it will inspect the pointer. If nonNull, it will call strlen
and strcpy to put the string info into a LV string. It will not free
the pointer as that is the normal behavior with returned string pointers.

Do you have problems
with this call, or are you just being cautious. If
you have problems, please be more specific.

Greg McKaskle

[RLD]

I prefer "cautious", (but paranoid might also apply). I had a bad experience back in the LV3/4 era when we forgot to size the string buffer connected to the input side of a string in the CLN argument list.

Thanks for the clarifications, I will "sleep better" now.

Rich