[rrd-developers] C# binding broken?

[Chris Larsen]

Hi Pellaeon,

>> First the good news: the fetch function seems to work now, but I get an
error in "Test_Restore();"
>> The console output is
>> test_a.xml:5: parser error: Input is not proper UTF-8, indicate encoding!
>> Bytes: 0xE4 0x69 0x73 0x63
>> Then the function does not return. The program hangs.

>> After debugging I can say the error occurs somewhere in the
"get_xml_element" function.
>> So is this a problem with the binding or a problem with the data from the
test example?

I'm guessing it's something to do with the rrdlib build in MSVC. Is the
"Character Set" configured for Unicode in MSVS? Also, try building rrdtool
with MSVS and run the same commands as the test code uses and let's see if
that exhibits the same characteristics. Since all of the actual parsing and
restoring happens in the dll, I don't think it would be a binding issue. I
ran the test (before the cdecl tweak) and passed that test alright. 

>> Second thing: In my opinion the calling convention must be cdecl!
>> [DllImport(dll,CallingConvention=CallingConvention.Cdecl)]
>> Standard calling convention of C/C++ is cdecl. Standard calling
convention of DLLImport is winapi what means: stdcall. So I changed all
calling conventions to
>> cdecl in the rrdlib.cs. But it seems there is no difference.
>> The error still occurs, it is still the same runtime behavior. So, only
in the sake of interest: why does the calling convention makes no
difference?
>> Normally wrong calling conventions result in corrupted stacks and so on?
>> Only happenstance?

I didn't worry much about calling conventions but I think you're right, it
should be cdecl after I did a little research. I'll mod that and re-submit a
patch.
Regarding no difference in behavior, the calling convention seems to
determine who cleans up the memory space (caller vs callee) and since the
binding test is just quickly iterating through the different methods and the
methods are written very well with regards to not sharing memory, I think
that's why we don't see any errors. If we were to run it on a loop and tried
to reuse some stuff, I bet we'd see memory leaks and errors piling up. I'm
getting ready to actually use this binding in a production system so I'll
try some looping tests then and see how it goes. 

Sincerely,
Chris