From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | emre(at)hasegeli(dot)com, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Redefining inet_net_ntop |
Date: | 2018-01-29 04:07:26 |
Message-ID: | 1704.1517198846@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> On 27 January 2018 at 04:27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Almost certainly, the thing to do is absorb updated code from bind,
>> not roll our own.
> I asked because I didn't see any comments explaining why we had it and why
> we built it even when the local system has support for it.
> I noticed because I was building an extension in C++ (yeah, fun) and it
> breaks because <inet/arpa.h>'s definition of inet_net_ntop is annotated
> with _THROW , which expands to throw() when building in c++. But this makes
> the prototype incompatible with the one we (re)declare in port.h without
> _THROW and causes #include "postgres.h" to fail.
Hm ... kinda proves my point about the local-system version not being
entirely stable :-(
> Sure, I can add a hack to c.h to define _THROW as a no-op when not on glibc
> and all that, assuming I get far enough with this extension to bother. But
> it made me ask why we have this duplication in the first place, hence this
> post.
In some other cases, we take the trouble to notice whether the system
headers provide a declaration for some function, and omit redeclaring
the function in port.h if so. That would be a cleaner answer than
trying to muck with _THROW, so far as the header is concerned, but
I'm not sure whether you'd still get an error when compiling
src/port/inet_net_ntop.c.
Another choice would be to stick a pg_ prefix on the function name.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-01-29 04:21:54 | Re: Boolean partitions syntax |
Previous Message | Amit Kapila | 2018-01-29 03:13:59 | Re: [HACKERS] why not parallel seq scan for slow functions |