Allocate memory in C++ .dll for a matrix of structures

[fcona]

Hi, now everything seems to work fine!

Here's how I changed my code, even if I'm still not super-convinced about the casting I did from UHandle to (LVecMeasHandle *)

void matrixMeasurement2Output(std::vector <std::vector <Measurement_t>> v2, LVecMeasHandle * o) {
    int offset = 0;
    MgErr err = 0;
    if (o == nullptr) {
        o = (LVecMeasHandle *)DSNewHClr(sizeof(LVMeasurement_t )*v2.size()*v2[0].size());

    } else {
        err = DSSetHSzClr(* o, Offset(LVecMeas, item)+sizeof(LVMeasurement_t )*v2.size()*v2[0].size());
    }
    if (!err) {
        for (auto v : v2) {
            for (auto m : v) {
                LVMeasurement_t * meas = LVecItem(** o, offset);
                measurement2Output(m, * meas);
                offset++;
            }
        }
        LMatS1(** o) = v2.size();
        LMatS2(** o) = v2[0].size();
    }
}

Thank you very much for your help!

Best,

Filippo

[rolfk · Accepted solution]

---

@fcona wrote:

Hi, now everything seems to work fine!

Here's how I changed my code, even if I'm still not super-convinced about the casting I did from UHandle to (LVecMeasHandle *)

---

With good rights!!!! DSNewHClr returns a handle, not a reference to a handle!!

if (o == nullptr) {
        *o = (LVecMeasHandle)DSNewHClr(Offset(LVecMeas, item) + sizeof(LVMeasurement_t )*v2.size()*v2[0].size());

Also you forgot to allocate space for the two dimension values in the front!!!

And now it is about testing, testing and testing even more. Stress test this really well. Just because it doesn't crash anymore does not mean that you got it all right. Buffer overflow errors are easily done but can often only cause problems much much later in your software execution when some routine tries to access memory that your overflow access corrupted. It can mean that half an hour later when you start some totally unrelated routine, things suddenly go downhill very fast!

Part of my testing of such code includes throwing everything at the routine that I can imagine, testing it on other platforms such a LabVIEW for Linux and testing it in multiple LabVIEW versions. This still doesn't guarantee anything but for sure randomizes the environment a lot more, such that errors like that can't hide as easily.

[fcona]

Hi, that was exactly my concern, but for some reason yesterday I couldn't get the code you suggest to compile, probably I did some stupid syntax error.

At this point I wonder what was the turning point: since the handle == NULL case clearly doesn't work, quite surely that piece of code is not executed and the overall behavior is identical to the old version of the function.

Best,

Filippo

[rolfk]

Yes it was most likely not executed. Maybe you connected some non-empty constant on the diagram to that parameter. However, since you pass the handle by reference, there is the chance that LabVIEW will pass in a NULL handle and your code of course should be prepared to deal with it. Even if you pass in a non-empty constant, some "smart" user of your VIs may think that that is really useless and emptying that constant would be a super handy optimization to speed up the program by a few nano-seconds. 😀

Defensive programming is a virtue and absolutely not useless! And if it is only to protect yourself in the future. That "smart" user may be very likely you in 3 months from now, when improving your routine and in the process of it you clean up the VIs. Been there and done that! 😁