> Regarding the hacks needed for configure to do good, did you add those to the
> raw configure shell script or have you done any nice configure.in changes?
 
I just hacked the raw configure script.
 
> And what exactly (again) did you need to do to get the select() and
> gettimeofday() recognized?
I bracketed the #include <limits.h> with #ifndef __hpux #endif
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char $ac_func (); below.
    Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
    <limits.h> exists even on freestanding compilers. */
#ifdef __STDC__
#ifndef __hpux
# include <limits.h>
#endif
#else
# include <assert.h>
#endif
I'm not quite sure why limits or assert needed to be included in the
first place. Probably something on some other platform.
> > That appear to stem from arbitrary use of stuff like socklen_t. On HP-UX,
> > the socket calls take socklen_t only if _XOPEN_SOURCE_EXTENDED is defined.
>
> What kind of pointers do these functions want when that define isn't
> set (which I guess it isn't when we build "normally")? The configure
> script tries to detect if there is a socklen_t typedef, and if not
> it defines one, but I figure this isn't enough for you here.
It is like this:
 getsockname(2) getsockname(2)
 NAME
      getsockname - get socket address
 SYNOPSIS
      #include <sys/socket.h>
    AF_CCITT only:
      #include <x25/x25addrstr.h>
      int getsockname(int s, void *addr, int *addrlen);
    _XOPEN_SOURCE_EXTENDED only (UNIX 98)
      int getsockname(int s, struct sockaddr *addr, socklen_t *addrlen);
    Obsolescent _XOPEN_SOURCE_EXTENDED only (UNIX 95)
      int getsockname(int s, struct sockaddr *addr, size_t *addrlen);
Without the _XOPEN_SOURCE_EXTENDED things are typically ints. As for
the configure check for socklen_t, looks like this is the code?
#include <sys/types.h>
#include <sys/socket.h>
int
main ()
{
if ((socklen_t *) 0)
  return 0;
if (sizeof (socklen_t))
  return 0;
  ;
  return 0;
}
There is nothing for socklen_t in types.h under UX, but in socket.h on
HP-UX 11.0 there is:
/*
 * Unix98 type used for certain objects in X/Open sockets APIs
 * whose size will not grow with the architecture, for example
 * socket address length.
 *
 * We choose a definition that is consistent with the Unix95
 * profile. However, in future implementations, we may choose
 * to limit the size to 32 bits in both 32-bit and 64-bit data
 * models.
 */
#ifdef _XOPEN_SOURCE_EXTENDED
typedef size_t socklen_t;
#else
typedef int socklen_t;
#endif /* _XOPEN_SOURCE_EXTENDED */
And so I suspect on 11.0 the warnings may not happen since a socklen_t
becomes an int. However, on 11.11 (where I am compiling) the relevant
section of socket.h simply reads:
/*
 * Unix98 type used for certain objects in X/Open sockets APIs
 * whose size will not grow with the architecture, for example
 * socket address length.
 *
 * We choose a definition that is consistent with the Unix95
 * profile. However, in future implementations, we may choose
 * to limit the size to 32 bits in both 32-bit and 64-bit data
 * models.
 */
typedef size_t socklen_t;
with no ifdefs. So, the test finds a socklen_t, that is a size_t, but
the socket calls are initially setup with ints. On the surface that
seems a bit inconsistent,but I suspect that it was either a) an
oversight, or b) a desire to avoid warnings in legacy code.
> > There are some others in url.c with parm5 of calls to Curl_write and
> > Curl_read that are not (?) XOPEN things:
> >
> > cc: "url.c", line 1441: warning 604: Pointers are not
> > assignment-compatible.^M
> > cc: "url.c", line 1441: warning 563: Argument #5 is not the correct
> > type.^M
>
> Not the correct type? Curl_write() has a prototype saying it wants a ssize_t
> pointer in parameter 5. The function too. And, in url.c line 1441 the
> '&written' argument very much looks like a ssize_t pointer to me.
>
> Do you understand what it wants?
At the risk of being labeled a pig, understanding the wants and
desires of a compiler is only slightly less daunting than
understanding the wants and desires of women :)
Anyhow... I just did another compile with _XOPEN_SOURCE_EXTENDED set.
In ftp.c I get:
cc -DHAVE_CONFIG_H -I../include -I../lib -I../lib -D_XOPEN_SOURCE_EXTENDED -c ft
p.c -Wp,-M.deps/ftp.TPlo +Z -DPIC -o .libs/ftp.lo^M
cc: "ftp.c", line 641: warning 604: Pointers are not assignment-compatible.^M
cc: "ftp.c", line 641: warning 563: Argument #1 is not the correct type.^M
This is:
    result = Curl_GetFTPResponse(&nread, conn, &ftpcode);
nread is a ssize_t up above.
However, in libs/ftp.c there is:
#ifndef CURL_DISABLE_FTP
CURLcode Curl_ftp(struct connectdata *conn);
CURLcode Curl_ftp_done(struct connectdata *conn);
CURLcode Curl_ftp_connect(struct connectdata *conn);
CURLcode Curl_ftp_disconnect(struct connectdata *conn);
CURLcode Curl_ftpsendf(struct connectdata *, const char *fmt, ...);
CURLcode Curl_GetFTPResponse(int *nread, struct connectdata *conn,
                             int *ftpcode);
CURLcode Curl_ftp_nextconnect(struct connectdata *conn);
#endif
In which the nread is specified as an int* rather than a ssize_t*.
The only reason that that definition does not generate a redeclaration
warning is that the actual routine is also defined with int*:
/*
 * Curl_GetFTPResponse() is supposed to be invoked after each command sent to
 * a remote FTP server. This function will wait and read all lines of the
 * response and extract the relevant return code for the invoking function.
 */
CURLcode Curl_GetFTPResponse(int *nreadp, /* return number of bytes read */
                             struct connectdata *conn,
                             int *ftpcode) /* return the ftp-code */
{
cc: "ftp.c", line 694: warning 604: Pointers are not assignment-compatible.^M
cc: "ftp.c", line 694: warning 563: Argument #1 is not the correct type.^M
Ditto.
cc: "ftp.c", line 725: warning 604: Pointers are not assignment-compatible.^M
cc: "ftp.c", line 725: warning 563: Argument #1 is not the correct type.^M
Ditto.
cc: "ftp.c", line 755: warning 604: Pointers are not assignment-compatible.^M
cc: "ftp.c", line 755: warning 563: Argument #1 is not the correct type.^M
Again :)
cc: "ftp.c", line 804: warning 604: Pointers are not assignment-compatible.^M
cc: "ftp.c", line 804: warning 563: Argument #1 is not the correct type.^M
cc: "ftp.c", line 835: warning 604: Pointers are not assignment-compatible.^M
cc: "ftp.c", line 835: warning 563: Argument #1 is not the correct type.^M
cc: "ftp.c", line 1175: warning 604: Pointers are not assignment-compatible.^M
cc: "ftp.c", line 1175: warning 563: Argument #1 is not the correct type.^M
cc: "ftp.c", line 1395: warning 604: Pointers are not assignment-compatible.^M
cc: "ftp.c", line 1395: warning 563: Argument #1 is not the correct type.^M
cc: "ftp.c", line 1643: warning 604: Pointers are not assignment-compatible.^M
cc: "ftp.c", line 1643: warning 563: Argument #1 is not the correct type.^M
cc: "ftp.c", line 1819: warning 604: Pointers are not assignment-compatible.^M
cc: "ftp.c", line 1819: warning 563: Argument #1 is not the correct type.^M
cc: "ftp.c", line 1832: warning 604: Pointers are not assignment-compatible.^M
cc: "ftp.c", line 1832: warning 563: Argument #1 is not the correct type.^M
and for the above... :)
Continuing, with _XOPEN_SOURCE_EXTENDED compilation:
cc -DHAVE_CONFIG_H -I../include -I../lib -I../lib -D_XOPEN_SOURCE_EXTENDED -c ur
l.c -Wp,-M.deps/url.TPlo +Z -DPIC -o .libs/url.lo^M
cc: "url.c", line 1441: warning 604: Pointers are not assignment-compatible.^M
cc: "url.c", line 1441: warning 563: Argument #5 is not the correct type.^M
This is:
  result = Curl_write(conn, sock, (char *)socksreq, (2 + (int)socksreq[1]),
                      &written);
arg five is &written. written is defined as an int:
  int actualread;
  int written;
  CURLcode result;
url.h defines Curl_write as:
/* internal write-function, does plain socket, SSL and krb4 */
CURLcode Curl_write(struct connectdata *conn, int sockfd,
                    void *mem, size_t len,
                    ssize_t *written);
with an ssize_t - the exact flip problem from ftp.c it would seem :)
yep, there is the definition in url.c:
/*
 * Curl_write() is an internal write function that sends plain (binary) data
 * to the server. Works with plain sockets, SSL or kerberos.
 *
 */
CURLcode Curl_write(struct connectdata *conn, int sockfd,
                    void *mem, size_t len,
                    ssize_t *written)
{
cc: "url.c", line 1448: warning 604: Pointers are not assignment-compatible.^M
cc: "url.c", line 1448: warning 563: Argument #5 is not the correct type.^M
This one looks liek the same thing with Curl_read...
cc: "url.c", line 1485: warning 604: Pointers are not assignment-compatible.^M
cc: "url.c", line 1485: warning 563: Argument #5 is not the correct type.^M
cc: "url.c", line 1491: warning 604: Pointers are not assignment-compatible.^M
cc: "url.c", line 1491: warning 563: Argument #5 is not the correct type.^M
cc: "url.c", line 1575: warning 604: Pointers are not assignment-compatible.^M
cc: "url.c", line 1575: warning 563: Argument #5 is not the correct type.^M
cc: "url.c", line 1581: warning 604: Pointers are not assignment-compatible.^M
cc: "url.c", line 1581: warning 563: Argument #5 is not the correct type.^M
Ditto for the above.
So, that seems to be why the compiler is issuing the warnings.
rick jones

-- 
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en