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: th
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 !U
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
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 als
Peter Eisentraut 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, or so tha
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
m
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:
http://www.
Andrew Dunstan 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 at turning thes
On 12/14/2012 11:33 AM, Tom Lane wrote:
Heikki Linnakangas 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
#define psql_assert(p) assert(p)
#else
...
On my Linux system, a failure lo
On 12/14/2012 11:33 AM, Tom Lane wrote:
Heikki Linnakangas 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
#define psql_assert(p) assert(p)
#else
...
On my Linux system, a failure lo
Heikki Linnakangas 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
> #define psql_assert(p) assert(p)
> #else
> ...
> On my Linux system, a failure looks like this:
> ~$ ./a
On 14.12.2012 17:54, Tom Lane wrote:
Andrew Dunstan 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,
Andrew Dunstan 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", \
>
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", \
__FILE__, __LINE__); \
abort()
14 matches
Mail list logo
