Re: patch: garbage error strings in libpq

From: Neil Conway <neilc(at)samurai(dot)com>
To: jtv(at)xs4all(dot)nl
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: patch: garbage error strings in libpq
Date: 2005-07-06 12:37:04
Message-ID: 42CBD070.9060101@samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

jtv(at)xs4all(dot)nl 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 between
> argument expressions, as per the paragraph you quote, the same must go for
> "c(x++,x++)". So then it becomes dubious that there is suddenly a
> guarantee for "c(a(),b())"!

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 that the evaluation of
libpq_gettext() is not interleaved with the evaluation of the other
arguments to the printf()?

-Neil

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2005-07-06 13:55:38 Re: Error handling fix in interfaces/libpq/fe-secure.c
Previous Message jtv 2005-07-06 10:35:47 Re: patch: garbage error strings in libpq