I'm working on implementing a client library for phd2 in rust, and I've come across an issue in the rpc response to get_star_image; the base64 encoded string in the pixels field is invalid because it has a null byte at the end. You can see it here, in the result of calling get_star_image against phd2 in simulator mode:
I believe this was added to the string in phd2 because of a simple misunderstanding of how to build strings using ostringstream because C strings are terminated with a null byte. The line I'm removing doesn't terminate the string, or tell ostringstream that it is time to build the string result; it adds a literal zero byte into the string. When that string is serialized out in the json response a zero byte is added before the string's terminating " character.
To make this a valid character in the json string, phd2 would need to append something like \\00000 (see the parse tree for string in the json spec) instead of \0. Doing this would put a zero byte in the deserialized json string, but it would then make it an invalid base64 encoding, as a zero byte is not one of the allowed 64 characters.
That's a lot of words to describe the problem, but the fix is pretty simple; stop putting a null byte in the end of the string.
With this change in place, the rpc response to get_star_image against phd2 in simulator mode looks like this:
d33psky
commented
1 year ago
I'm working on implementing a client library for phd2 in rust, and I've come across an issue in the rpc response to
get_star_image; the base64 encoded string in thepixelsfield is invalid because it has a null byte at the end. You can see it here, in the result of callingget_star_imageagainst phd2 in simulator mode:Note the
\0near the end of the string.I believe this was added to the string in phd2 because of a simple misunderstanding of how to build strings using ostringstream because C strings are terminated with a null byte. The line I'm removing doesn't terminate the string, or tell ostringstream that it is time to build the string result; it adds a literal zero byte into the string. When that string is serialized out in the json response a zero byte is added before the string's terminating
"character.To make this a valid character in the json string, phd2 would need to append something like
\\00000(see the parse tree for string in the json spec) instead of\0. Doing this would put a zero byte in the deserialized json string, but it would then make it an invalid base64 encoding, as a zero byte is not one of the allowed 64 characters.That's a lot of words to describe the problem, but the fix is pretty simple; stop putting a null byte in the end of the string.
With this change in place, the rpc response to
get_star_imageagainst phd2 in simulator mode looks like this: