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_g
Here's another one similar to what I described in my previous message. In
libpq's pqsecure_read(), if SSL_read() returns -1 and sets an error of
SSL_ERROR_SYSCALL, errno may be polluted by libpq_gettext() before a
human-readable string is derived from it. Also, pqReadData() will see the
wrong err
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> Another approach would have been to make libpq_gettext() preserve errno.
>
> That seems like a far easier, cleaner, and more robust fix than this.
Provided that either:
(a) the C standard has added a sequence point between the arguments in a
function
Tom Lane wrote:
> The gettext function does not modify the value of the global errno
> variable. This is necessary to make it possible to write something like
>
> printf (gettext ("Operation failed: %m\n"));
>
> which is pretty much what I expected to find. Ergo, this entire
>
Neil Conway wrote:
> Per C99 6.5.2.2.10, a sequence point occurs between the evaluation of
> the arguments to a function and the call of the function itself.
> Therefore a sequence point occurs before the call to libpq_gettext(). So
> ISTM having libpq_gettext() preserve errno should work.
In C99
Neil Conway wrote:
> The text is the same in both versions:
>
> http://dev.unicals.com/papers/c89-draft.html#3.3.2.2
>
> "The order of evaluation of the function designator, the arguments, and
> subexpressions within the arguments is unspecified, but there is a
> sequence point before the actual ca
Neil Conway wrote:
> Tom Lane wrote:
>> I think this is all irrelevant language-lawyering; jtv spotted the true
>> problem which is that we do not protect errno during the *first* call of
>> libpq_gettext.
>
> I think you're missing the point. Obviously the curren
Tom Lane wrote:
>
> (1) The fact that gettext works at all seems to me to be sufficient
> empirical evidence that it's a working solution.
Tom, you have GOT to be joking. I agree with some of the things you say
(see below), but here you're just not making sense. Consider:
1. We're only talking
Tom Lane wrote:
>> That would answer the big question here, but where does it say that? I
>> saw Neil's point that the sequence points before function calls apply
>> for
>> the nested calls as well as the outer one, but there is no ordering
>> between those "nested-call" sequence points. It's all
Tom Lane wrote:
>> That would answer the big question here, but where does it say that?
>
> Also, if you really insist on an authoritative statement, try this text
> (from Annex D of the C99 draft standard, "Formal model of sequence
> points"):
Thank you, that would answer the question. There is
Stephan Szabo wrote:
> I believe overlap of functions in the same expression was disallowed by
> the response to defect report 087. The only reference I've been able to
> find right now (since the committee seems to have removed the C89 DRs from
> their site) is in the response to DR 287 which in
11 matches
Mail list logo
