Re: [Bug-wget] Wget 1.13.4 on True64 OSF1 Beta

[Steven M. Schweda]

From: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <address@hidden>

> >    The problem seems to originate in "netinet/in.h":
> I assume that's the system header provided by Tru64, not by something
> else.

   Sorry for the missing info.  Yes, that was the DEC/Compaq/HP-supplied
"/usr/include/netinet/in.h".  Suggestive content:

/*
 * @DEC_COPYRIGHT@
 */
[You have to admire the quality of this stuff.]
/*
 * HISTORY
 * $Log: in.h,v $
 * Revision 4.3.57.3  2003/11/13  22:42:42  Brian_Haley
[... and (much) older ...]

   This stuff is not especially new.

> Such definition makes very little sense, as that would mean the system
> supports two different a struct sockaddr_in, and would somehow need to
> differenciate between them in api calls.

   You mean like this (/usr/include/sys/socket.h)?:

[...]
#if defined(_SOCKADDR_LEN) && \
    !defined(_KERNEL) && \
    !defined(_XOPEN_SOURCE_EXTENDED) && \
    !defined(_POSIX_PII_SOCKET)

#define recv            _recv_OBSOLETE_ /* use recvfrom */
#define send            _send_OBSOLETE_ /* use sendto   */
#define accept          naccept
#define getpeername     ngetpeername
#define getsockname     ngetsockname
#define recvfrom        nrecvfrom
#define recvmsg         nrecvmsg
#define sendmsg         nsendmsg

#endif /* _SOCKADDR_LEN && !_KERNEL && !_XOPEN_SOURCE_EXTENDED && 
!_POSIX_PII_SOCKET*/
[...]

   It makes _plenty_ of sense, _if_ you need to maintain compatibility
with old code.  DEC (in the old days) was usually pretty careful about
that, and they had old Ultrix customers to consider.

> Is there any versioning for that in the header? Eg. the functions connect
> being #defined to a different name depending on those same macros.

   I see nothing which I would call real versioning on Tru64, just
_SOCKADDR_LEN.  On VMS, socket.h includes the following:

[...]
/*
**  Strict XPG4 V2 compliance requires the BSD 4.4 socket interfaces,
**  which is only available on OpenVMS V7.0 or later
*/
#if defined _XOPEN_SOURCE_EXTENDED && !defined _SOCKADDR_LEN && __CRTL_VER >= 
70000000
#   define _SOCKADDR_LEN 1
#endif
[...]

whose reference to __CRTL_VER may qualify as "versioning", but that's on
VMS (and requires that someone define _XOPEN_SOURCE_EXTENDED to get the
full effect).


> Does man connect give any hint?

   Yes:

[...]
      [Tru64 UNIX]   If the compile-time option _SOCKADDR_LEN is defined
      before the sys/socket.h header file is included, the sockaddr structure
      takes 4.4BSD behavior, with a field for specifying the length of the
      socket address. Otherwise, the default 4.3BSD sockaddr structure is
      used, with the length of the socket address assumed to be 14 bytes or
      less.

      If _SOCKADDR_LEN is defined, the 4.3BSD sockaddr structure is defined
      with the name osockaddr.
[...]


   As one might expect, the details are more complicated than I had
appreciated.  In "/usr/include/sys/socket.h", the "sa_len" member in
"struct sockaddr" is conditional:

[...]
#if defined(_SOCKADDR_LEN) || \
    defined(_KERNEL) || \
    defined(_XOPEN_SOURCE_EXTENDED) || \
    defined(_POSIX_PII_SOCKET)
/*
 * Structure used by kernel to store most
 * addresses.
 */
struct sockaddr {
        unsigned char   sa_len;         /* total length */
        sa_family_t     sa_family;      /* address family */
        char            sa_data[14];    /* actually longer; address value */
};
[...]
#else   /* BSD4.3 */

struct sockaddr {
        unsigned short  sa_family;      /* address family */
        char            sa_data[14];    /* up to 14 bytes of direct address */
};
[...]


   Similarly, in "/usr/include/netinet/in.h", the "sin_len" member in
"struct sockaddr_in" is conditional:

[...]
/*
 * Socket address, internet style.
 */
#if defined(_SOCKADDR_LEN) || defined(_KERNEL) || \
                        defined(_XOPEN_SOURCE_EXTENDED)
struct sockaddr_in {
        unsigned char   sin_len;
        sa_family_t     sin_family;     /* New typedef for Spec 1170 */
        in_port_t       sin_port;       /* New typedef for Spec 1170 */
        struct  in_addr sin_addr;
#ifdef _XOPEN_SOURCE_EXTENDED
        unsigned char   sin_zero[8];    /* Changed type from char to     */
                                        /* unsigned char for Spec 1170   */
#else
        char    sin_zero[8];
#endif
};
#else
struct sockaddr_in {
        unsigned short  sin_family;
        unsigned short  sin_port;
        struct  in_addr sin_addr;
        char    sin_zero[8];
};
#endif
[...]


   But, as the alert reader will have observed, the two conditions are
not the same, and "./config.h" here defines _POSIX_PII_SOCKET:

[...]
/* Define to 1 in order to get the POSIX compatible declarations of socket
   functions. */
#define _POSIX_PII_SOCKET 1
[...]

which is what causes "struct sockaddr" and "struct sockaddr_in" not to
conform.  Interestingly, this seems to be the result of a
non-test-program decision in "configure" (twice):

[...]
        case "$host_os" in
    osf*)

$as_echo "#define _POSIX_PII_SOCKET 1" >>confdefs.h

      ;;
  esac
[...]


   So, the smart thing to do may be to add a definition of _SOCKADDR_LEN
where _POSIX_PII_SOCKET is being defined.  (Perhaps _SOCKADDR_LEN should
replace _POSIX_PII_SOCKET in these spots, but I don't have any old
versions of Tru64, or any non-Tru64 OSF/1 systems, so I can't run any
serious tests on that.  As I showed, adding a definition of
_SOCKADDR_LEN seems to solve the problem on Tru64 V5.1B.  I don't know
what would break where if the definition of _POSIX_PII_SOCKET were
removed, and I'm not eager to find out.)


   Also in "./config.h" here:

[...]
/* Define to 1 if `sa_len' is a member of `struct sockaddr'. */
#define HAVE_STRUCT_SOCKADDR_SA_LEN 1
[...]

This is true, but no one seems to care about the corresponding details
of "struct sockaddr_in".

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

   Steven M. Schweda               address@hidden
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547