I am developing a very simple application which should behave accordingly to a stream of data coming from a TCP Socket.
I have managed to make the network part work, but now I have encountered a very strange behaviour. When I receive data from the network I convert it into a string using the integrated functions, like this:
TArray<FRotator> UNetworkBlueprintLibrary::GetRotationPacket(){
bool bDataPresent;
uint32 netData;
int32 bytesRead;
TArray<FRotator> tempData;
uint8 receivedData[100];
bDataPresent = UNetworkBlueprintLibrary::ServerSocket->HasPendingData(netData);
if (netData >= 16) {
UNetworkBlueprintLibrary::ServerSocket->Recv(receivedData, (int32) 100, bytesRead);
FString debugData = BytesToString(receivedData, bytesRead);
// Writing received data to log
UE_LOG(NetworkInfo, Warning, TEXT("Got message %s"), *debugData);
}
return tempData;
}
I will have to fix some things as the code is not very good, but I was just testing. The application behaves accordingly, receives the message and then outputs what’s in the buffer on the LOG screen in the Editor.
What’s strange is that, even if the message is:
Server: Welcome 127.0.0.1
What gets written in the LOG dialog is:
Got message Tfswfs;!Xfmdpnf!238/1/1/2
Which… Looks like the message with each of the characters increased by one. After checking my code I decided to check the definition of BytesToString
, and it looks like this:
/**
* Convert an array of bytes to a TCHAR
* @param In byte array values to convert
* @param Count number of bytes to convert
* @return Valid string representing bytes.
*/
inline FString BytesToString(const uint8* In, int32 Count)
{
FString Result;
Result.Empty(Count);
while (Count)
{
// Put the byte into an int16 and add 1 to it, this keeps anything from being put into the string as a null terminator
int16 Value = *In;
Value += 1;
Result += TCHAR(Value);
++In;
Count--;
}
return Result;
}
Oh, ok! Now I get it, the function adds one to each character in the string because… Reasons, I suppose, as I don’t understand why they should not allow null terminators inside FStrings. If I remember correctly they should be null-terminated strings, but there might be a reason behind this behaviour.
Is there a function to use a FString that has been encoded this way?
Or, better yet, should I change that code and sent a pull request to the GIT repository?