> void decode_char_test (int *ptr_readbuf, int size_buffer, unsigned int > *ptr_writebuf, int *n_elements, unsigned int Y, unsigned int N); >
The problem here is that your DLL call is both consuming an array of characters, and returning an array of integers, and the DLL doesn't allocate either buffer. It relies on you to allocate the buffers for it, and tell it how much space is there. If this information doesn't match, it isn't a bug in the DLL, but in the usage of it. First make sure that size_buffer is correct. It should be the size of the data that is passed in as ptr_readbuf. Usually this will be in elements, but it can be in bytes or anything else the DLL expects. If this is too small, the DLL will not crash, but will not read all of the data in your buffer. If it is too big, it will read past the buffer and either read garbage memory, or cause an exception because it is reading memory that isn't mapped into the LV process. The second thing to look at is n_elements and ptr_writebuf. For this, you have to allocate a buffer and tell the DLL how many elements it is safe to write there. To allocate the buffer, you can use a constant array, initialize array, or any other properly sized array wire of the correct type that you don't mind the DLL writing on. You wire the array into the left as the buffer, and the modified array wires out the right. If the count you wire to the DLL is too small, the DLL will not use the entire buffer and may not return all of the values. If it is too large, the DLL will write past the true end of the buffer and will either corrupt memory or cause an exception because it is accessing memory that isn't mapped into the LV process. I hope this makes sense. It isn't really that hard once you understand what the DLL needs to do and that it can't touch either allocation since it cannot return any new pointers to you. All the DLL can do is rely on the caller to pass in consistent information about the buffers and do the allocations correctly. Greg McKaskle
