cpluspluscheck is having issues with this change:
In file included from /tmp/cpluspluscheck.QEdLaR/test.cpp:3:0:
./src/include/postgres_fe.h:34:0: warning: Assert redefined [enabled by
default]
In file included from /tmp/cpluspluscheck.QEdLaR/test.cpp:2:0:
src/include/postgres.h:673:0: note:
On 12/16/2012 01:29 AM, Peter Eisentraut wrote:
On Fri, 2012-12-14 at 17:03 -0500, Tom Lane wrote:
Having the layer is a good thing, eg so that USE_ASSERT_CHECKING
can control it, or so that somebody can inject a different behavior
if they want.
You could also (or at least additionally) map
On Fri, 2012-12-14 at 17:03 -0500, Tom Lane wrote:
Having the layer is a good thing, eg so that USE_ASSERT_CHECKING
can control it, or so that somebody can inject a different behavior
if they want.
You could also (or at least additionally) map !USE_ASSERT_CHECKING to
NDEBUG. This would also
On Fri, 2012-12-14 at 15:32 -0500, Andrew Dunstan wrote:
Here's a patch for that.
It appears that your change has caused new compiler warnings:
encnames.c:9:1: warning: Assert redefined
In file included from encnames.c:8:
../../../src/include/postgres_fe.h:36:1: warning: this is the location of
Andrew Dunstan and...@dunslane.net writes:
As I'm working through the parallel dump patch, I notice this in one of
the header files:
#ifdef USE_ASSERT_CHECKING
#define Assert(condition) \
if (!(condition)) \
{ \
write_msg(NULL, Failed assertion in %s, line %d\n, \
On 14.12.2012 17:54, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
As I'm working through the parallel dump patch, I notice this in one of
the header files:
#ifdef USE_ASSERT_CHECKING
#define Assert(condition) \
if (!(condition)) \
{ \
write_msg(NULL,
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 14.12.2012 17:54, Tom Lane wrote:
BTW, I think psql already has a psql_assert.
psql_assert looks like this:
#ifdef USE_ASSERT_CHECKING
#include assert.h
#define psql_assert(p) assert(p)
#else
...
On my Linux system, a failure looks
On 12/14/2012 11:33 AM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 14.12.2012 17:54, Tom Lane wrote:
BTW, I think psql already has a psql_assert.
psql_assert looks like this:
#ifdef USE_ASSERT_CHECKING
#include assert.h
#define psql_assert(p) assert(p)
#else
...
On
On 12/14/2012 11:33 AM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 14.12.2012 17:54, Tom Lane wrote:
BTW, I think psql already has a psql_assert.
psql_assert looks like this:
#ifdef USE_ASSERT_CHECKING
#include assert.h
#define psql_assert(p) assert(p)
#else
...
On
Andrew Dunstan and...@dunslane.net writes:
I noticed, BTW, that there are one or two places in backend code that
seem to call plain assert unconditionally, notably src/port/open.c,
src/backend/utils/adt/inet_net_pton.c and some contrib modules. That
seems undesirable. Should we need to look
On 12/14/12 11:33 AM, Tom Lane wrote:
Works for me. So just rename that to Assert() and move it into
postgres-fe.h?
Or just call assert() and don't invent our own layer?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 12/14/2012 04:23 PM, Peter Eisentraut wrote:
On 12/14/12 11:33 AM, Tom Lane wrote:
Works for me. So just rename that to Assert() and move it into
postgres-fe.h?
Or just call assert() and don't invent our own layer?
Well, part of the point is that it lets you use Assert() in code that
Peter Eisentraut pete...@gmx.net writes:
On 12/14/12 11:33 AM, Tom Lane wrote:
Works for me. So just rename that to Assert() and move it into
postgres-fe.h?
Or just call assert() and don't invent our own layer?
Having the layer is a good thing, eg so that USE_ASSERT_CHECKING
can control it,
13 matches
Mail list logo
