# Why does this LibraryLink example of LinkObject based passing not work? Bug or user error?

There's an example of LinkObject-based passing in the LibraryLink documentation. Unfortunately the cell in the documentation notebook is corrupted, but to skip that problem I'm going to reproduce it in plain text here:

funLink = LibraryFunctionLoad["demo_LinkObject", "reverseString", LinkObject, LinkObject];


On OS X I get the output LibraryFunctionError["LIBRARY_FUNCTION_ERROR", 6] instead of the expected drawrof. On Windows it works. Looking at the source code of the example, I cannot immediately see what's wrong with it. A precompiled version of this example library comes with Mathematica, and it's what the above commands should load (verified with FindLibrary). So I tried recompiling it, but the error is still there.

You'll find the complete source code in:

SystemOpen@FileNameJoin[{\$InstallationDirectory, "SystemFiles", "Links", "LibraryLink", "LibraryResources", "Source"}]


Question: Is this a bug in LibraryLink/MathLink itself? Or is there a flaw in the example program that I didn't find?

• as you are asking many LibraryLink related questions lately, may I ask what you are working on? – Albert Retey Aug 21 '15 at 8:56
• @AlbertRetey I need small simple things that are better done in C(++) from time to time, sometimes things as simple as shuffling around the edges of a graph. I find writing or extending LibraryLink code cumbersome because of all the boilerplate that's necessary and limitations with multiple return or strings (both solved by MathLink) or LinkObject passing). I tried to automate writing the boilerplate with a package and by using C++. – Szabolcs Aug 21 '15 at 9:45
• @Albert At this point this package is really just an experiment to discover what would work well in practice (through actually using it) rather than the final result. I tried to ask for feedback on it, but got little. Due to lack of time, I think I'll keep it for personal use only for now, and based on the experience I get with it, maybe in the far future, I'll try again. It would be nice to make it easy to add translation rules for various types (more than what LibraryLink supports). But now it's not even clear if this is worth it over just using the more flexible MathLink. – Szabolcs Aug 21 '15 at 9:48
• There's also this C++-side-only solution which people told me just after I started. It's probably better done as my C++ is rusty and not up to date with C++11. – Szabolcs Aug 21 '15 at 9:50
• OK, thanks for the information, that all sounds interesting. I just was wondering, but it is good to know who to ask when having questions :-). I have myself used LibraryLink only to pass around largish numeric arrays in pure C and found that working very well and efficient and I think for that purpose LibraryLink is better suited than MathLink. So far I have no experience with anything else, though... – Albert Retey Aug 21 '15 at 10:01

I think the issue is that the demo source file hasn't been properly updated. Originally it used MLCheckFunction, which was later deprecated in favor of MLTestHead. There is, however an incompatible change in the type of the last argument: MLTestHead takes a pointer to int, while MLCheckFunction used to take a pointer to long.

The following test fails

DLLEXPORT int reverseString( WolframLibraryData libData, MLINK mlp)
{
int res = LIBRARY_FUNCTION_ERROR;
int i1, i2, sum;
long len;
const char *inStr = NULL;
char* outStr = NULL;

if ( !MLTestHead( mlp, "List", &len))
goto retPt;
if ( len != 1)
goto retPt;
.
.
.
}


as explained in the answer by Szabolcs: it would only work correctly on Windows, where long and int are both 32-bit.

After changing the declaration to

int len;

and recompiling, the example works again:

funLink["forward"]

(* "drawrof" *)


The same applies for the other example function, addtwo.

• 4 minutes apart :) – Szabolcs Aug 21 '15 at 16:38
• It seems with Interface Version 3 it's also an int, but MLCheckFunction (deprecated in 4) has a long. – Szabolcs Aug 21 '15 at 16:44
• @Szabolcs Yes, that's absolutely right. I've corrected the answer (though perhaps I should just delete it, it doesn't add anything to yours). – ilian Aug 21 '15 at 17:23

This is due to a bug in the example code. Specifically, in reverseString, the type of variable len should be int and not long because MLTestHead expects an int *. From the docs, the prototype is

int MLTestHead(MLINK link, const char *head, int *n)


On Windows with MSVC long and int are of the same size but on 64-bit OS X they are not, so MLTestHead writes a 4-byte int into len, leaving the remaining 4 bytes alone and causing long len to have an essentially unpredictable value. Then if ( len != 1) fails.

Had I only used "ShellOutputFunction" -> Print with CreateLibrary, I would have seen the compiler warning. But I was stupid and I didn't.