fix malfunction of socket functions on HP-UX in 64-bit mode

[Bruno Haible]

On 64-bit HP-UX, socklen_t is defined as the 64-bit type 'size_t';
however the system calls getsockname() etc. read only the first 32 bits
from &addr_len.  Because the endianness is BIG_ENDIAN, this reads as 0,
and thus these system calls don't fill in an address in the supplied
buffer (but nevertheless return 0).  This problem is known to HP for
15 years [1]. Their response is described in "man xopen_networking" [2].

Namely, they first provided a fix that consists in linking with -lxnet.
Then they realized that this approach breaks all code (e.g. in libraries)
that assumes that the functions take an 'int *' (old BSD convention)
rather than a 'socklen_t *'.

So they now provide a different fix, namely wrappers called _xpg_getsockname
etc., which is enabled by defining the macro _HPUX_ALT_XOPEN_SOCKET_API.

But they don't enable this second fix by default!!

This fix works only when the appropriate feature macros are defined, but this
is not a problem in practice:
  - If you use CC="cc +DD64 -AC99", the compiler will add -D_HPUX_SOURCE=1
    by default.
  - If you use CC="cc +DD64 -AC99 -D_XOPEN_SOURCE=500", the compiler will
    automatically add -D_HPUX_SOURCE=1 -D_XOPEN_SOURCE_EXTENDED

Here's what I'm committing for gnulib:
1) A test case for getsockname() that highlights the problem: It fails
   on HP-UX in 64-bit mode (but succeeds in 32-bit mode).
2) A modification of the 'extensions' module to define the
   _HPUX_ALT_XOPEN_SOCKET_API macro.

With this fix, the getsockname test now works also in 64-bit mode.

[1] https://marc.info/?l=hpux-devtools&m=106742181731126&w=2
[2] https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c02281864

0001-getsockname-tests-More-tests.patch
Description: Text Data

0002-Fix-malfunction-of-socket-functions-on-HP-UX-in-64-b.patch
Description: Text Data