Re: socklen_t on HP/UX

[Bob Proulx]

Dustin J. Mitchell wrote:
> As you probably know, on HP/UX, accept, getpeername, et al. take (..,
> int *addrlen), not (.., socklen_t *addrlen) unless _XOPEN_SOURCE and
> _XOPEN_SOURCE_EXTENDED are defined.  However, if these macros are not
> defined, socklen_t is still defined.

There are a few more problems too.  This is from memory, I can check
later, but as I recall 64-bit HP-UX defines socklen_t incorrectly to
be long.  IIRC it was long in both 32-bit and 64-bit environments.  It
should have been int.  This led to failures in the 64-bit compile.

> This means that the test in socklen.m4 doesn't have any effect (as it
> finds the type already defined).  The result is code that compiles,
> but because of the endianness of the 64-bit processor, fails at
> runtime.

As I recall it was a size mismatch and not an endian mismatch.
Because the size was mismatched the data was in the half that wasn't
being used by the subroutine.  IIRC data was stuffed into a 64-bit
variable but then used as a 32-bit variable internally.  The portion
used was the most significant portion which was all zero.  (It has
been a few years and I might have details wrong.)  However I think we
are in agreement that it didn't work.  :-}

> I think it would make sense to run the compile check even if socklen_t
> is defined.  What I don't know is what to do if it turns out that
> socklen_t is the wrong type to pass to these functions?  "#undef
> socklen_t\n#define socklen_t int"?  Or try to use a type with a
> different name, e.g., socklen_t_equiv, throughout the source code?

I have a snippet of code that does just that, or rather exactly this:

  #if defined(__hpux)
  #undef socklen_t
  #define socklen_t int
  #endif

With a FIXME comment that I never got back to about the problem being
64-bit compiles using the native HP ANSI C/C++ compiler in 64-bit mode
defining socklen_t to a long so that sizeof (socklen_t) != sizeof (int).

> I'm trying the latter solution within Amanda, since I can replace all
> uses of socklen_t without much trouble.  Is there a way to solve this
> within gnulib, though?

That would be nice.

Bob