Re: C# binding broken?
"Chris Larsen" <[email protected]>
| Newsgroups | gmane.comp.db.rrdtool.devel |
|---|---|
| Message-ID | <[email protected]> |
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