Thread: AW: compilation problem on AIX

> Does somebody have solution for this problem that was discussed here a month ago?
>
> >>
> >> the stream functions on AIX need a size_t for addrlen's in fe-connect.c and pqcomm.c.
> >>This has come up before.  AIX wants size_t for certain structures like
> >getsockname().  I believe the third parameter on AIX is size_t, while it
> >used to be int on my machine, but is not socklen_t.  Is this correct?
> >The 'int' code works fine for me, but I can see why AIX is having a
> >problem, and perhaps it is time for configure to check on the various
> >types.
> >
> >    getsockname(int s, struct sockaddr *name, socklen_t *namelen);
>
> Ok, so this gets tricky. In 4.2.1 it is size_t and in 4.3.1 it is as above with socklen_t :-(

I would simply do:

#ifndef size_t
typedef int size_t
#endif

#ifndef socklen_t
typedef size_t socklen_t
#endif

and use socklen_t which is now standard for socket functions

Andreas

PS.: I am back from "vacation" and am now happy father of our 16 day old daughter Hannah :-)

> PS.: I am back from "vacation" and am now happy father of our 16 day
> old daughter Hannah :-)

Congratulations! We'll smoke a virtual cigar to celebrate.

                      - Tom

Andreas Zeugswetter <andreas.zeugswetter@telecom.at> writes:
> I would simply do:

> #ifndef size_t
> typedef int size_t
> #endif

> #ifndef socklen_t
> typedef size_t socklen_t
> #endif

That has no hope of working, since typedefs generally are not macros.

Marc had the right idea: a configure test is the only real way to
discover how getsockname() is declared.  A small problem is that
configure can only detect outright compilation failures, not warnings.
That's probably good enough, but people with nonstandard definitions
of getsockname may have to live with looking at warnings.

> and use socklen_t which is now standard for socket functions

It is?  The machines I have access to think the parameter is plain,
unvarnished "int".

            regards, tom lane

> Marc had the right idea: a configure test is the only real way to
> discover how getsockname() is declared.  A small problem is that
> configure can only detect outright compilation failures, not warnings.
> That's probably good enough, but people with nonstandard definitions
> of getsockname may have to live with looking at warnings.

Just redeclare the function with the parameters you expect. Most compilers
will fail if you redeclare with parameters of different types or different
number of parameters, but silently ignore functionally identical prototype
lines.

Taral