patch: garbage error strings in libpq - Mailing list pgsql-patches

From jtv@xs4all.nl
Subject patch: garbage error strings in libpq
Date
Msg-id 14697.202.47.227.25.1120562769.squirrel@202.47.227.25
Whole thread Raw
Responses Re: patch: garbage error strings in libpq
List pgsql-patches
Several libpqxx users have been reporting odd problems with certain error
messages generated by libpq.  One of them was the inclusion of garbage
data.

As it turns out, src/interfaces/libpq/fe-misc.c contains several instances
of this construct:

  printfPQExpBuffer(&conn->ErrorMessage,
    libpq_gettext("error: %s"),
    SOCK_STRERROR(SOCK_ERRNO, buffer, sizeof(buffer)));

This may occur in other source files as well.  On Unix-like systems,
SOCK_ERRNO defines to plain errno--which is likely to be overwritten by
the libpq_gettext().  I'm attaching a patch that fixes these instances by
introducing a named pointer to the SOCK_STRERROR message, initialized
before either of the other function calls.

Another approach would have been to make libpq_gettext() preserve errno.
It's tempting, but I'm not sure it would be valid from a language-lawyer
point of view.  There is no sequence point between the evaluations of
libpq_gettext() and SOCK_STRERROR().  From what I vaguely remember hearing
somewhere in the distant past, that means that theoretically they may be
evaluated not just in any order but even in parallel.  I guess it may
actually happen if both inlining and scheduling are sufficiently
aggressive.  Even if libpq_gettext() is made to restore errno, it will
still have to pollute errno at some points during its execution.


Jeroen

Attachment

pgsql-patches by date:

Previous
From: Marko Kreen
Date:
Subject: Re: [HACKERS] [PATCH] pgcrypto: pgp_encrypt v3
Next
From: jtv@xs4all.nl
Date:
Subject: Error handling fix in interfaces/libpq/fe-secure.c