Re: Rejecting part of HURD PAM patch--help appreciated

[Sam Hartman <hartmans@debian.org>]

>>>>> "Marcus" == Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

    Marcus> On Sat, May 25, 2002 at 02:43:15PM -0400, Sam Hartman
    Marcus> wrote:
    >> I'm rejecting several hunks related to maxhostnamelen and
    >> maxpathlen.  The patch radically changes the behavior of the
    >> code if these two symbols are not defined using dynamic
    >> allocation rather than asserting a reasonable maximum buffer
    >> length.  I think I would be happy saying you should always do
    >> dynamic allocation and never use the preprocessor symobl, but
    >> I'm not happy introducing dynamic allocation sometimes.

    Marcus> Well, on the GNU/Hurd system, the code will always use
    Marcus> dynamic allocation because we never define those symbols.
    Marcus> On all other systems I know it will always use static
    Marcus> allocation.

This is my problem.  The patch as written introduces different
behavior on HURD when no such difference is justified.

I would be happy either defining some arbitrary maximum to be
consistent with other platforms or improving the overall quality of
the code and  removing the need for the static buffer.
    Marcus> If the purpose of your mail was to get someone verufy the
    Marcus> patch for correctness on other platforms, then please make
    Marcus> this clear in your reply.  I don't have time to proof read
    Marcus> it right now, but what sticks out is that getline is only
    Marcus> available in the GNU C library, so that is a potential
    Marcus> incompatibility.  An autoconf check and a replacement
    Marcus> function in a helper library could fix this.

While not strictly the purpose of my mail, this was what I expected
would be the best thing to do.  I'll get around to doing that
verification eventually but if you or someone in the hurd community
gets around to it before I do, that would be appreciated.  Or rather
gets around to identifying other issues besides getline.

I'll probably be uploading to experimental in a day or so, and that
version probably will not work on the HURD.  I suspect that upstream
changes will also have introduced problems that need to be dealt with.
I expect similar problems for the BSD folks.

When the module is in experimental I'll send mail here and to
debian-bsd so people can give it a look before I upload to unstable in
a week or two.


-- 
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org