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
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
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:
>
> (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
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
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:
> 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
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
>
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
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
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
11 matches
Mail list logo
