Re: patch: garbage error strings in libpq

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 easy when you
>> have
>> a total ordering, but we're in a partial ordering here.
>
> This is utter nonsense.  If the sequence points within a function do not
> follow (in an execution-order sense) the one at the call site, then no C
> program on the planet will manage to work.

That's not what I said though.  In retrospect you could interpret it that
way, but what would be the point in choosing an obviously nonsensical
interpretation?  Yes, the sequence points within a function obviously
follow the function point marking the call itself.  But that's beside the
issue.  It's already implicitly assumed in everything we say here, as I'm
sure you're aware.  When I say 'those "nested-call" sequence points' I
refer to the two sequence points marking the two respective nested calls.

Here's the problem again: we have two calls to respective functions a()
and b(), each call of course marked by a sequence point (call them a0 and
b0) and each function comprising a string of sequence points internally
(say a1a2..an and b1b2..bm) whose internal order must be respected.  No
problem so far, I hope.  a1a2 etc. must be performed in that order and
b1b2 etc. must be performed in that order.  But no ordering is imposed
between a0 and b0!

Now, if there is a requirement somewhere in the standard that says, like
you say, that the execution of two function calls may not be interleaved,
then we're in the clear.  But I didn't find anything to say that.  Absent
that guarantee AFAICS the compiler is allowed to pick any interleaving of
a() and b() that respects their respective strings of sequence points:
a0b0a1b1a2b2 would do, or b0b1a0a1b2a2, and so on.  If that is the case,
then your proposed solution may start to fail mysteriously as compilers
progress.

And now that we're on the subject, shouldn't the default cases of the SSL
error-code switches in pqsecure_read() and pqsecure_write()
(src/interfaces/libpq/fe-secure.c) restore errno as well?


Jeroen