AC_FUNC_ACCEPT_ARGTYPES is falling down on the job

I was a little startled to find that current sources refuse to compile
on a rather old redhat release (4.2).  The observed failure is

pqcomm.c: In function `StreamConnection':
pqcomm.c:314: `socklen_t' undeclared (first use this function)

which is pretty reasonable seeing that socklen_t is in fact not defined
anywhere in /usr/include on this system.  What's not reasonable is that
configure is selecting socklen_t as the value of ACCEPT_TYPE_ARG3.
Looking into it, I find that AC_FUNC_ACCEPT_ARGTYPES is in fact failing
completely: every single combination it tries fails with errors like

configure:4749: gcc -c -O2   conftest.c 1>&5
configure:4743: conflicting types for `accept'
/usr/include/sys/socket.h:375: previous declaration of `accept'

and it then defaults to 
 ac_cv_func_accept_arg1=int ac_cv_func_accept_arg2='struct sockaddr *' ac_cv_func_accept_arg3='socklen_t'

which is not too bright considering that it has just proven that
that combination will not work.

The proximate cause of the failure is that this platform actually
declares accept as

int accept __P ((int __sockfd, __const struct sockaddr *__peer,               int *__paddrlen));

so it would seem that you need to try "const struct sockaddr *"
(and perhaps "const void *"?) as one of the possibilities for
ac_cv_func_accept_arg2.  However I also suggest that

1. If we fail to get any combination to compile, configure should
abort, not press on with a default combination that is guaranteed
not to work.

2. If sys/socket.h doesn't exist or doesn't provide a prototype for
accept(), then the first combination tried will "succeed".  As coded,
this is int / struct sockaddr * / socklen_t, which may be POSIX-standard
but I wonder how likely it is to work on platforms that are too old to
have prototypes in sys/socket.h.  Perhaps size_t would be a safer thing
to try first.
        regards, tom lane