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

From jtv@xs4all.nl
Subject Re: patch: garbage error strings in libpq
Date
Msg-id 18836.202.47.227.25.1120793633.squirrel@202.47.227.25
Whole thread Raw
In response to Re: patch: garbage error strings in libpq  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
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 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 this his interpretation is correct,
> but it is a question worth resolving.

Agree totally.  If my interpretation is wrong then I'll happily get on
with my life and let everyone else do the same.  I was at that point once
already, but Neil took another close look at the relevant part of the C
standard he dug up and found this potential problem.

I really don't like playing the smart-alec language lawyer here, but I've
been following compiler developments and they are moving in a direction
that makes this relevant.  I do want to be sure that we're shipping
correct code, not just code that practically speaking suppresses the
symptoms of its bugs for a while, on most compilers, for the most popular
CPU architectures.

Moreover, I don't want to go through all of this again when the regression
occurs and we think we've solved it forever and the problem must be
somewhere else.  I've been losing enough sleep over what I thought must be
bugs in libpqxx that I just couldn't put my finger on.


Jeroen



pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: A couple of p.tches for PostgreSQL 64bit support
Next
From: Neil Conway
Date:
Subject: Re: Patch to remove deadcode from dbcommands.c