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

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.

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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> 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.

I still want to understand why any change is needed at all. There must
be something very peculiar about getaddrinfo on Tru64 if the original
coding doesn't work. Why is it different from every other function we
test for?

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > 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.
>
> I still want to understand why any change is needed at all. There must
> be something very peculiar about getaddrinfo on Tru64 if the original
> coding doesn't work. Why is it different from every other function we
> test for?

I have the answer. Tru64 netdb.h has:

#if defined (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED)
#define getaddrinfo ngetaddrinfo
#else
#define getaddrinfo ogetaddrinfo
#endif

so it is a macro, and configure produces this line:

#undef $ac_func

meaning that even if we added #include <netdb.h>, our configure test
still would not work.

Perhaps we should just test for ngetaddrinfo on that platform, and
define HAVE_GETADDRINFO.

--
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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I have the answer. Tru64 netdb.h has:

> #if defined (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED)
> #define getaddrinfo ngetaddrinfo
> #else
> #define getaddrinfo ogetaddrinfo
> #endif

Seems like the same method we use for testing finite() and other
possible-macros would handle this, then.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I have the answer. Tru64 netdb.h has:
>
> > #if defined (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED)
> > #define getaddrinfo ngetaddrinfo
> > #else
> > #define getaddrinfo ogetaddrinfo
> > #endif
>
> Seems like the same method we use for testing finite() and other
> possible-macros would handle this, then.

OK, patch attached. I did the macro test you suggested. Would someone
test this on Tru64?

--
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