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
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 |