(fwd from mbp@samba.org) CVS update: rsync

[Martin Pool]

On  8 Aug 2001, Albert Chin-A-Young <china at thewrittenword.com> wrote:

> > Sorry, this is obviously wrong.  Passing the wrong type will only give
> > a warning on C, whereas I think it will give an error on C++.

[BTW, I meant my blithely changing it to C was wrong; your suggestion
was fine. :-]

> I'm not having much luck here. Doing this in C is hard. BTW, did you
> run into any problems by defining socklen_t to int as the default?

Simply doing AC_CHECK_TYPE breaks on HP/UX 11.00 and 11.11 since it is
not declared in sys/types.h.  There may be a workaround for that -- I
haven't looked closely at what autoconf produces for AC_CHECK_TYPE.

I'm not sure if that is the only problem: I don't think it's enough.

The killer case is a machine which has 32-bit ints, 64-bit size_t (and
parameter to sockaddr), and no sockaddr_t.  I wouldn't be surprised if
such a thing exists.

By the way the Debian unstable autoconf2.13 / 2.50 transition fights
with their libtool but I have filed a bug and expect it to be fixed
soon.

The propagation delay to test this on the samba build farm (10-60
minutes) makes debugging it a bit tiresome.  Still I guess it's the
only realistic way to get access to a Cray.

> I think redeclaring the prototype for getpeername seems to be an
> interesting idea. I'm going to try this (this is kinda hairy though as
> not all platforms have the first two parameters identical).

I tried that.  I haven't given up by I'm not using it at the moment.
I think it failed because gcc declares other strange attributes like
the C99 __restrict that cause the declaration to not match.  It may be
possible to fix.

tridge's suggestion was something like

  char lenarry[16], data[1];

  fd = make_connected_loopback_tcp_socket();
  bzero(lenarry, sizeof lenarry);
  getpeername(fd, &data, (void *) &lenarry);

  grovel through lenarry to work out how much of it was actually
  filled with a number.

This is pretty gross because for every function that I can see the
argument passed in has to be initialized beforehand, so we can't just
fill it with 0xff.

Another idea is to run the compilation as you suggested, but look at
stderr for warning messages.  Keep trying the compilation until we not
only get success but also get nothing on stderr.  This is more likely
to get false negatives, if there is something broken about the
platform or test case that makes it always output errors even if we've
guessed the right type.

Yet another is to grep the headers for the getpeername (or setsockopt,
or whatever) declaration and try to work out the third parameter from
there.  This is a bit error-prone, again because there can be
comments, attributes, or other wierd things in the declaration.

Alternatively we could just look at the OS type, but there's a certain
strange satisfaction in working out autoconf tests that do it all by
deduction. :-)

--
Martin