Jason Petersen wrote:
> I realize Postgres’ codebase is probably intractably large to begin
> using a tool like splint (http://www.splint.org ), but this is exactly
> the sort of thing it’ll catch. I’m pretty sure it would have warned in
> this case that the code relies on an ordering of side effects that is
> left undefined by C standards (and as seen here implemented
> differently by two different compilers).
Well, we already have Coverity reports and the VIVA64 stuff posted last
month. Did they not see these problems? Maybe they did, maybe not, but
since there's a large number of false positives it's hard to tell. I
don't know how many false positives we would get from a Splint run, but
my guess is that it'll be a lot.
> The workaround is to make separate assignments on separate lines,
> which act as sequence points to impose a total order on the
> side-effects in question.
Not sure how that would work with a complex macro such as ereport.
Perhaps the answer is to use C99 variadic macros if available, but that
would leave bugs such as this one open on compilers that don't support
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: