Creating a pointer to void to pointer

[JonasM]

It's quite large program with lots of dependencies, i Will work on it tomorrow and try to clean it a bit, cant really stans for the code as is 😛 I dont have My laptop with me home today

[JonasM]

The driver is provided by the manufacturer to us, we can't find it on the website of theirs. So we want to be a bit cautious to share the whole lib that we made. But if we get it cleared by next week I can post the project I've been working on and explain which calls does what for the forum to see if there might be any smart fixes that will solve it.

However the functions say that if they had success they will return 1 and 0 otherwise, we have had 0 a lot and now with the latest code everything is just success. So I'm not sure how they wont have success without having it.. But I'm sure there is some miss in sizes or something simple like that. I'll get back with more code later on if possible.

[rolfk]

The problem with a function returning success is that it only can control so much, such as that the passed in parameters contain sensible values, arrays are passed in as actual pointer (which in most cases is only a check to be anything but NULL).

There is no reliable way a function can control that the array of bytes you pass in as a pointer is actually a real pointer and not just some random gibberish that happens to be not NULL. Equally there is no real way for a function to check that that array pointer has been properly allocated on the heap or stack to be large enough to hold the necessary information. If the programmer is smart he requires some kind of length indication for any incoming array parameter, be it a 0 byte termination for strings, or an explicit parameter that tells the function how big the buffer is.

For outgoing parameters the API should provide an extra length parameter in which the caller can tell the function how big of a buffer he actually has allocated. If the API doesn't and just assumes that the caller sure enough provided a big enough buffer then that is a sure way to allow for buffer overruns. This still doesn't prevent the caller to tell the function that he allocated a buffer of 10000 elements while in reality he only allocated 10000 bytes or less. For arrays other than byte arrays there is definitely a problem about telling a function you allocated a buffer that can hold for instance 10000 single precision floats, while in reality it only can hold 10000 bytes. This will also likely provoke a buffer overrun, unless the function happens to only need to fill in 2500 elements or less.

Buffer overruns are generally not directly detectable. In the best case the memory behind the buffer is not mapped into the current process or is located on the stack and the buffer overrun simply causes a general protection error, but most times it is inside a larger heap allocation where other data of the application is stored and the buffer overrun trashes that, causing the application to crash later or even more evil, work with invalid number or string values that might be difficult to detect.

[JonasM]

Thanks for the detailed answer rolfk, we do see quite random crashes even after we got this function returning data as of yesterday. We have made a huge buffer though for testing purposes so I'm not sure what is crashing our app.. might be what your last paragraph mentions.. as of yet we cannot share the full dll. As it's provided only with purchase of a product.

anyway we have managed to get it working now when we actually configured the trigger settings correct. The initial post by nathand on how to pass the data worked.

now we have some work to do with the provider of instrument to see if we can figure out why the app crashes, same thing in visual studio works perfect without crashes. So might be a tricky one.

many thanks too both of you nathand and rolfk! Our heads are no longer under water 😉