reinterpret_cast for received tcp packets

[Redman]

@J-Hilk Since there are no plans of switching to a different Compiler than MSVC I did not consider that.
I would assume that

#pragma pack(push, 1)
#pragma pack(pop)

would do the same through all MSVC versions.

Regarding that reinterpret_cast, I will, as you suggested, implement a ctor which takes a QByteArray.
In fact, I already tried that out during figuring out what the actual problem was. To me the ctor looked "ugly".
Doing byteArray.sliced(i,n) to retrieve the corresponding bytes and casting them to the desired type might be a quick thing to implement for such a small struct. But for larger structs this gets ugly very fast.

Since c++ doesn't offer reflection, can I somehow use Qt's meta-object system to achieve a dynamic construction of my object?

[jsulm]

I also would not assume indianess based on operating system. Windows also runs on ARM and ARM can be both big or little.

[Redman]

@jsulm Thats why we tested both :)

[J.Hilk]

@Redman I would suggest using QDataStream

[Christian Ehrlicher]

Casting a struct to a received bunch of bytes is not correct. It may work now but fail as soon as a small piece changes. Therefore you have to describe the bytes on the paket (e.g. in an interface document) and decode them accordingly. Everything else is a hack.

[JonB]

@Redman said in reinterpret_cast for received tcp packets:

@JonB I do this during the whole execution time of my application. The tcp packet size is only 22 bytes, so fairly small.
How would I go about making sure I get all the bytes out of the buffer?

Assuming recEchoDataReady() is called as a slot from readyRead() signal, what you are supposed to do is append the bytes to a "pending" buffer and then check whether the total number read into pending equals or exceeds the number you need/expect for your struct. If so remove those from pending. Not only might you be "short" (read only 1+ bytes when 22 expected), you might also "overflow" (read e.g. 32 when 22 wanted for one packet because it also finds some of the next packet), in which case that packet will "work" but the next packet will go wrong.

If you don't want to do this, because you believe it is always 22, you might at least put in a QASSERT(bytes_read == sizeof(Coordinate)) to verify that never goes wrong.

You say a lot about the struct size/packing/padding/endianness etc. at the receiving C++ side but did not answer how you send the data from the Python side. If I understand right you have looked at "the wire" or the bytes you receive and say they don't look right as raw bytes? In which case check the sender side. I believe you are saying that it used to work when the sender was C++ but now goes wrong when the sender is Python, in which case the receiver side is irrelevant and the bytes sent must be different, if that is really the case.

01:00:00:00:01:00:01:00:00:00:01:00:00:00:00:00:00:00:01:00:00:00

Unfortunately after casting that ByteArray to my struct I get following values

1 1 65536 65536 -1870011232

While this seems to contradict the statement that it is the sender side which has changed/gone wrong, I would examine this more closely. Off the top of my head that data buffer would not produce the (packed) struct values you say it does.

You also wrote at one point:

@Redman said in reinterpret_cast for received tcp packets:

Fixed the problem.

Does this mean you no longer have any problem sending/receiving the structure? You introduced the #pragma pack(push, 1), did that fix, was that at C++ receiver side or what did you do at Python sender side? Your C struct needs to be packed if you expect it to be 22 bytes size.

[Redman]

@Christian-Ehrlicher The interface is well documented and both sites agreed to it. So there will be no change to that without further discussion between me and our partner :)

[J.Hilk]

@Redman said in reinterpret_cast for received tcp packets:

The interface is well documented and both sites agreed to it. So there will be no change to that

[Christian Ehrlicher]

@Redman said in reinterpret_cast for received tcp packets:

The interface is well documented and both sites agreed to it.

Then you would not have asked any of the questions above nor any problems wrt connecting to another process.

[Redman]

@Christian-Ehrlicher And you live in a perfect world where no problems occur? :)

[Christian Ehrlicher]

@Redman said in reinterpret_cast for received tcp packets:

And you live in a perfect world where no problems occur?

No, but your questions/problem revealed a basic lack of a "well documented" interface.