ports/96918: sysutils/fcron: fcrondyn completely broken

[Brad Huntting]

> never mind. i have a problem with the postfix MTA re. local (unix)
> sockets, where code and error message look remarkably similar. this
> isn't all that urgent, but at somepoint in the future i'll have to
> tackle it.

> is there a reason why linux-code differs slightly from fbsd as far as
> connect(2) is concerned? is your patch the "canonical" way of dealing
> with it?

The problem is that BSD (as of Net2 or Reno) changed (struct sockaddr)
(and all the family specific versions such as (struct sockadder_un)
to add a length field (sa_len, or sun_len) which needs to be set
to the length of the struct (or zeroed out so it's deliberately
ignored).  As usual, Linux chose to emulate the old way rather than
adopting the new sockaddr convention.

Since so much code today is writen for Linux, this has become a
common problem with anything that uses unix domain sockets.

The generic fix is to add code to configure.in and config.h.in.in to
set HAVE_SA_LEN.  Then, when filling in the struct sockaddr before
a connect or bind, use #ifdef HAVE_SA_LEN and fill in the sun_len
field.  This is the bulk of the patch in PR ports/97066.  Note, in
this case, the code leading up to connect() was did not correctly
check the path length and called strncpy() with incorrect arguments,
so I had to fix that too.

But, yes, the changes to configure.in and config.in.in are generic
enough they should be useable with anything that uses gnu configure
just place the added lines in the right place.  Then add the
appropreate #ifdefs when setting up the socket address before bind
and connect.  Such a patch should be ecumenical enough that it can
be sent to the original code maintainer.  After all, FreeBSD is not
the only system to use sa_len.


hope that helps,
brad