Important: Please read the Qt Code of Conduct - appends null char

  • Hi all -

    My app reads a UDP socket and processes the message. I need to test for a complete message, as determined by the presence of a end tag.

    The call appends a null character to the QByteArray that is causing the endsWith() function to fail.

    QByteArray endTag("</XML>\n\0");
    QByteArray right =;
    qDebug() << endTag << endl << right << endl <<;
    if (

    Note that my effort to append a null character to my endTag fails; at least as shown by the qDebug() call. Also, the test fails.

    I cannot reproduce this problem using only QByteArrays; it has something to do with the data() call.

    I could easily hack a solution, but I'm wondering if anyone knows why this is happening, and whether it might be a bug.

    5.14.2, Windows 10.


  • Lifetime Qt Champion

    @mzimmers How do you send the datagram? I don't think data() appends anything.

  • @jsulm this is an incoming datagram, processed by a slot that picks up readyRead().

  • Lifetime Qt Champion


    first you should check the datagram in wireshark.

    I also doubt the null byte is random.


  • @aha_1980 the null char is indeed part of the data. But I wasn't expecting it to be added to the QByteArray (my error I guess).

    So, given that this is occurring within a slot, I'm trying to minimize the amount of data copying I'm doing. I'm assuming I can't edit the datagram itself, can I? So, how do I construct my endTag so that my compare will return true? It seems weird that my code example doesn't keep the null.

  • Lifetime Qt Champion

    @mzimmers how do you know it doesn't keep the null byte?

    Try qDebug() << endTag.toHex().


  • @aha_1980 well for one thing the endsWith() returns false. Here's the hex for all three arrays:

     qDebug() << endTag.toHex() << endl << right.toHex() << endl <<;

    Strange, no?

  • Lifetime Qt Champion

    @mzimmers ah, got it. you cannot embed \0 in a C-string... QByteArray is unguilty.

    try endTag.append('\0'); instead.


  • @aha_1980 very good...that works:

                QByteArray endTag("</XML>");
                if (

    So, is there a preferred way for me to build my endTag? Ideally it would be a const, given that this is a slot (and therefore something of an ISR), and performance is important.


  • Lifetime Qt Champion

    @mzimmers if you can use C++11, raw string literals come to mind. otherwise you could make the variable a membr and keep it for multiple invocations.

  • @aha_1980 how would using raw string literals allow me to embed a null char (or newline)?

  • A little inflexible, but you can set byte size manually

    const QByteArray endTag("</XML>\n\0", 8);

  • @mzimmers
    \n has never been a problem. You are going to have problems trying to embed any extra \0 inside a " string. You could spell it out via { '<', '/', ... '>', '\0' } but you may not like readability. Do you need the \0 to actually be there, could you deal with that in code instead?

    If you want to be naughty/impressive(?): QByteArray stores an extra \0 at the end anyway, always! It's not included in count/size(), but it is there, and documented ( So you could use the one which is there. Personally not sure I would, but up to you... :)

  • Bonnie's solution is perfect. For my education, though...why doesn't it work without the length specifier, but works with it? I'm working with a QByteArray, so I don't see how C-string rules apply, unless the argument (the stuff in quotes) is being interpreted as a C-string...

  • @mzimmers
    Yes, the parameter in QByteArray endTag("</XML>\n\0") is what you call a C string. The fact that is being passed to, say, a QByteArray constructor does not alter this fact. When QByteArray copies the characters from there it stops at the first \0. When @Bonnie specifies the length explicitly in his constructor call it copies the 8 characters he specifies.

    The problem is that you have to maintain this for every literal token you have, and one day you'll get the byte count out of sync with the string next to it. Which is why I would do your whole thing in code, I really don't think you're doing yourself any favours by playing around with literals here when it's not necessary. Why don't you reconsider?

  • Thanks for the's been educational.

    Now, if I could just get someone to help me in the installer forum (heh)...

Log in to reply