On Fri, Aug 29, 2025 at 10:45:18PM +0300, Ran Benita wrote:
> I used PQtrace to trace a logical decoding session, and was confused to see
> lines like this:
>
> 2025-08-29 22:09:57.633980 F 38 CopyData
'r\x00\x00\x00\x00\xffffff8e\x07\xffffff85x\x00\x00\x00\x00\xffffff8e\x07\xffffff85x\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\xffffffe0\xffffff84\xffffff89R\xffffffd7\xffffffb8\x00'
>
> The data doesn't make sense and has the wrong length. A quick look shows that
> the \xffffff85 parts are a signedness issue (on my compiler char is signed).
>
> @@ -212,7 +212,7 @@ pqTraceOutputNchar(FILE *pfdebug, int len, const char *data, int *cursor, bool s
> else
> {
> fwrite(v + next, 1, i - next, pfdebug);
> - fprintf(pfdebug, "\\x%02x", v[i]);
> + fprintf(pfdebug, "\\x%02x", (unsigned char) v[i]);
> next = i + 1;
> }
> }
Yeah. Not a lot of people use the libpq tracing, but it would be
better to show non-printable data in a consistent way.
> The diff below fixes this particular problem, though they say bugs are like
> mushrooms, if you find one then there are probably others nearby, so a more
> comprehensive fix may be warranted.
There's one more mushroom: pqTraceOutputByte1() also uses a %02X
without a cast for non-printable data. Note as well
logicalmsg_desc(), auth-oauth.c, mbprint.c (which uses an unsigned
char type in input to force things).
--
Michael
