Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] [PATCH] Better way to check for getaddrinfo

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "R, Rajesh (STSD)" <rajesh(dot)r2(at)hp(dot)com>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: [HACKERS] [PATCH] Better way to check for getaddrinfo
Date: 2006-01-26 17:38:50
Message-ID: 200601261738.k0QHcoU11730@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackerspgsql-patches
I am not sure what to do on this.  Right now we have a one-line test:

    AC_REPLACE_FUNCS([getaddrinfo])

To test for a macro we are going to need to add include netdb.h, and the
LINK test below is overkill.  I am thinking we should just hard-code in
HAVE_GETADDRINFO for the True64 platform;  anything more is going to be
just a Tru64 hack anyway.

---------------------------------------------------------------------------

R, Rajesh (STSD) wrote:
> sorry. It is a macro.
> 
> so, would it be better to check for the macro
> as suggested by Tom or go with this patch
> 
> $ diff -r configure.in configure.in.new
> 918a919
> > AC_MSG_CHECKING([for getaddrinfo])
> 920c921,926
> <   AC_REPLACE_FUNCS([getaddrinfo])
> ---
> >  AC_TRY_LINK([#include <netdb.h> #include <assert.h>],
> >                 [char (*f)();f=getaddrinfo;],
> >   ac_cv_func_getaddrinfo=yes, ac_cv_func_getaddrinfo=no)
> > if test x"$ac_cv_func_getaddrinfo" = xyes; then
> >   AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the getaddrinfo
> function])
> > fi
> 923a930
> > AC_MSG_RESULT([$ac_cv_func_getaddrinfo])
> 
> 
> I guess, instead of adding seperate code for macro checking as suggested
> by Tom, this might serve dual purpose.
> 
> Thanks,
> Rajesh R
> --
> This space intentionally left non-blank.
> 
> -----Original Message-----
> From: Martijn van Oosterhout [mailto:kleptog(at)svana(dot)org]
> Sent: Tuesday, January 24, 2006 2:46 PM
> To: R, Rajesh (STSD)
> Cc: Tom Lane; pgsql-hackers(at)postgresql(dot)org; pgsql-general(at)postgresql(dot)org
> Subject: Re: [HACKERS] [GENERAL] [PATCH] Better way to check for
> getaddrinfo function.
> 
> On Tue, Jan 24, 2006 at 02:33:13PM +0530, R, Rajesh (STSD) wrote:
> > Its not a macro.
> > I meant that the code generated by AC_REPLACE_FUNCS([getaddrinfo]) by
> > configure.in for "configure"
> > does not have "#include <netdb.h>". Hence function is not
> > detected(unresolved getaddrinfo).
> > Hence  I thought AC_TRY_LINK could give test program instead of
> > AC_REPLACE_FUNCS taking one.
> 
> But if it isn't a macro, why do you need the header file? In C it's
> perfectly legal to declare the symbol yourself and try to link and it
> should work *unless* it's normally a macro.
> 
> We're still missing some necessary understanding here...
> 
> Have a nice day,
> --
> Martijn van Oosterhout   <kleptog(at)svana(dot)org>   http://svana.org/kleptog/
> > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is
> > a tool for doing 5% of the work and then sitting around waiting for
> > someone else to do the other 95% so you can sue them.
> 
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2006-01-26 17:49:19
Subject: Re: Backslashes in string literals
Previous:From: Bricklen AndersonDate: 2006-01-26 17:07:16
Subject: Re: Rollback Mountain

pgsql-patches by date

Next:From: Tom LaneDate: 2006-01-26 17:45:00
Subject: Re: BUG #2195: log_min_messages crash server when in DEBUG3 to
Previous:From: Tom LaneDate: 2006-01-26 16:06:43
Subject: Re: BUG #2195: log_min_messages crash server when in DEBUG3 to 5

pgsql-general by date

Next:From: Tom LaneDate: 2006-01-26 17:40:49
Subject: Re: Access Problem After Version Upgrade -- Update
Previous:From: Jim ButtafuocoDate: 2006-01-26 17:36:07
Subject: Re: Access Problem After Version Upgrade -- Update

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group