Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net

> Hajimu UMEMOTO <ume_at_freebsd.org> writes:
> > Dag-Erling Smørgrav <des_at_des.no> writes:
> > > You can't just bump libpam; you need to bump all the modules along
> > > with it, because libpam will only load modules with the same major
> > > number as itself.  In fact, there is only a single SHLIB_MAJOR for the
> > > entire src/lib/libpam tree, in src/lib/libpam/Makefile.inc.
> > Thank you for clarification.  My patch bumps SHLIB_MAJOR in
> > lib/libpam/Makefile.inc.
> 
> As PAM maintainer, I strongly object.

Keep in mind that systemic changes can trump a maintainer's
objection.  This is a systemic change, so your single objection is not
necessarily enough to not do this.  However, the issues you raise may
be reason enough to revert the systemic change.

> > > Is it really necessary to remove the padding?  It gives us a lot of
> > > trouble for zero gain.
> > I think such cleanup should be done before major release.
> 
> What do we gain from removing the padding?  Is there even a single
> practical benefit to doing so?

It is for posix compatibility.

http://lists.freebsd.org/pipermail/freebsd-standards/2005-May/000869.html

is where to start for an explaination.

The question becomes one of do we care enough about 5.x compatibility
with our new architectures to preserve it.  The RE has indecated that
he'd really like to see us do that (ABI stability).

Warner