Re: Redefining inet_net_ntop
От | Tom Lane |
---|---|
Тема | Re: Redefining inet_net_ntop |
Дата | |
Msg-id | 1704.1517198846@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Redefining inet_net_ntop (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: Redefining inet_net_ntop
|
Список | pgsql-hackers |
Craig Ringer <craig@2ndquadrant.com> writes: > On 27 January 2018 at 04:27, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: