Congratulations to our 2022 Qt Champions!

Is it possible to allocate an unsigned char[] within an else statement????

  • My code is as follow:
    QByteArray tmp_Buffer = _port->readAll();

                if (tmp_Buffer.length())
                    unsigned char temp[tmp_Buffer.length()];
                    qMemCopy(&temp[0], &[0], tmp_Buffer.length());
                    emit LogMsgChanged(temp, sizeof(temp));
                    ParseReceiveMsg(temp, rx_data);

    But the variable temp does not seem to be allocated properly...

  • I'm not sure if all compilers support variable length arrays on the stack. With gcc on a Mac it works for me in a simple test program.

    BUT: If your slot is not called synchronously it might be that the execution flow in the sending object left the scope of the inner if-statement when your slot gets called. At this point in time the temp array is already destroyed and you have a dangling pointer in your slot!

    Why don't you pass the QByteArray as argument to the signal? That would save you the qMemCopy and Qt handles all the reference counting for you.

  • Fully agree with Volker here. There are too much things to take into account when not using a reference counted or copied object here.

  • as far as i know array lengthes need to be const at compile time, i had a similar error long time ago.

    but you could try this:
    char* temp = (char*)malloc(tmp_buffer.length);
    memcpy(temp,, tmp_buffer.length);

  • From a C++ perspective better use:

    char *temp = new char[tmp_buffer.length()];
    memcpy(temp,, tmp_buffer.length);
    // do some work
    delete[] temp;

    It's important to use delete[] rather than delete without brackets!


    • no need for a cast
    • the same syntax as with objects on the heap
    • no sizeof necessary

    BTW: to be on the safe side one should use

    malloc(sizeof(char) * length);

    and of course not forget to call free(temp) after the malloc'ed memory isn't required anymore :-)

    Regarding compiler support:
    At least gcc does support variable length arrays on the stack as an extension to the C standard (and therefore in C++ too). With other compilers your mileage may vary. I would not depend on it, anyways. As I would avoid raw arrays of pointers wherever I can, too :-) (or put them at least into a nice object which cleans up in the destructor)

  • Uhm, forgot something very important:

    On the same pointer

    • use T *x = new T() and delete x
    • or T *x = new T[ 42] and delete[] x
    • or T *x = (T *)malloc(sizeof(T) * 42) and free(x)

    never, never, never mix any of these on the same pointer!

    Of course one can use x = new and y = malloc in the same program, just use delete on x and free on y.

  • i work with vs compiler i think this compiler has problems with variable length arrays but not sure anymore.

    @Volker thanks for the annotations and explanations

    Is there a reason why i should use free for a pointer that was allocated with malloc instead of deleting it?

  • Yes. You definitely want to avoid earth destruction :-)

    To be serious: There are several reaseon, among them:

    • The memory allocation from new might not be the same as with malloc, so the pools are messed up if you mix them
    • new/delete call the constructors/destructors of objects whereas malloc/free only give you a bunch of bytes without any meaning.

    You can find some more background infos in the "Freestore management": Chapter of the C++ FAQ.

Log in to reply