Tom Lane writes ("Re: Old GCC bug affecting postgresql error handling"):
> Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> > Alex Deiter appears to have tried to report this to gcc upstream:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968
> > However, the test program in that bugzilla report is indeed broken.
> > The gcc maintainers were right to reject the bug.
>
> Hm --- it's a bit questionable. The test execution appears to show
> that the side-effect of program abort happens before the printf call;
> but depending on how much buffering of stdout is happening, it might
> not really prove that.
As it happens in actual fact in the example program, the stdout output
is indeed buffered so the observed behaviour is exactly what one would
expect if the program had been compiled naively without any
optimisation.
However, also, undefined behaviour doesn't respect causality. If your
program's behaviour is ever undefined, the whole behaviour is
undefined. (C99 3.4.3.) So even if you made stdout unbuffered, or
wrote to stderr, the same observed behaviour is permissible.
> Your version is a lot more conclusive, at least
> as far as Postgres' issue is concerned, because in our case we know
> the ereport() function won't return.
Right.
> > I have tried to reproduce the original problem with a smaller test
> > program (see below) than postgresql, but failed (on 32-bit sparc with
> > gcc 4.4.5-8, Debian squeeze).
>
> I wonder whether the gcc folk reconsidered and fixed the problem
> somewhere between 4.1.x and 4.4.x. I've seen them reverse course
> before on what was or wasn't a bug.
I wasn't able to do a test of the actual current postgresql with a
current Debian compiler. The original report is on sparc64 which is a
bit difficult as I can't find any sparc64 porter box.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
