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
On Sat, 9 Jul 2005 [EMAIL PROTECTED] wrote:
> 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
> > poin
[EMAIL PROTECTED] wrote:
Thank you, that would answer the question. There is no "also" about it;
it's exactly what I was asking all along. The conclusive answer for us
would be in the C89 standard of course, where (at least in the draft that
Neil quoted) I haven't been able to find anything lik
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
[EMAIL PROTECTED] writes:
> 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"):
D.2.2 Function calls
[EMAIL PROTECTED] writes:
> 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
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 current code is wrong,
> the debate is ov
Neil Conway <[EMAIL PROTECTED]> writes:
> I think you're missing the point. Obviously the current code is wrong,
> the debate is over the best way to fix it. Jeroen's interpretation of
> the spec suggests that merely having libpq_gettext() preserve errno is
> not sufficient. I'm not convinced th
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 current code is wrong,
the debate is over the best way to fix it. Jero
Neil Conway <[EMAIL PROTECTED]> writes:
> Right; my interpretation is that the "sequence point before function
> call" rule applies recursively. So in c(a(...), b(...)), there are in
> fact three sequence points, which precede the calls of a, b, and c.
> Shouldn't that be sufficient to ensure th
[EMAIL PROTECTED] wrote:
That is pretty much what I remember hearing at the time.
A well-known way to trigger undefined behaviour is "x++=x++;" because
there is no sequence point between the two side effects. Try it: gcc will
give you a stern warning. Given that there is no sequence point be
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
[EMAIL PROTECTED] wrote:
Does anyone know what the situation is in C89, or whatever the applicable
standard is?
[ *looks* ]
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
sube
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
[EMAIL PROTECTED] wrote:
(a) the C standard has added a sequence point between the arguments in a
function call, which AFAIK wasn't there before, or the sequence point was
there all along (and the compiler implements it);
Per C99 6.5.2.2.10, a sequence point occurs between the evaluation of
th
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
[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.
Moreover I don't believe that this approach works either, as the result
of strerror() is not guaranteed still usable after an
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
20 matches
Mail list logo
