QNetworkDatagram.data() appends null char

aha_1980

first you should check the datagram in wireshark.

I also doubt the null byte is random.

Regards

mzimmers

@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.

aha_1980

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

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

Regards

mzimmers

@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 << m_datagramIn.data().toHex();

"3c2f584d4c3e" 
"3c2f584d4c3e0a00" 
"3c584d4c3e3c5061636b6574547970653e526573706f6e73653c2f5061636b6574547970653e0a3c50726f647563744e616d653e45544320537065616b65723c2f50726f647563744e616d653e0a3c53657269616c4e756d3e3435373030303030323c2f53657269616c4e756d3e0a3c4d6163416464723e30303a32303a66373a30343a32613a37643c2f4d6163416464723e0a3c4950416464723e31302e31302e302e3135343c2f4950416464723e0a3c4465764e616d653e494320456e61626c656420506167696e6720416d703c2f4465764e616d653e0a3c444843503e456e61626c65643c2f444843503e0a3c2f584d4c3e0a00"

Strange, no?

aha_1980

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

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

Regards

mzimmers

@aha_1980 very good...that works:

            QByteArray endTag("</XML>");
            endTag.append('\n');
            endTag.append('\0');
            if (m_datagramIn.data().endsWith(endTag))
            {

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.

Thanks...

aha_1980

@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.

mzimmers

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

Bonnie

A little inflexible, but you can set byte size manually

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

JonB

@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 (https://doc.qt.io/qt-5/qbytearray.html#details). So you could use the one which is there. Personally not sure I would, but up to you... :)

mzimmers

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...

JonB

@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?

mzimmers

Thanks for the help...it's been educational.

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