Re: Rejecting part of HURD PAM patch--help appreciated
On Sat, May 25, 2002 at 02:43:15PM -0400, Sam Hartman 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.
Well, on the GNU/Hurd system, the code will always use dynamic allocation
because we never define those symbols. On all other systems I know it will
always use static allocation.
We would be happy with just eliminating the static allocation case, and use
dynamic allocation on all systems in all cases. That is something that
doesn't effect us, but we believe it is the right thing to do anyway.
The reason the patch was written the way is probably two things: First, it
changed the code only for platforms which didn't compile before, and kept it
the same on all other platforms. This is a conservative approach, in case
the new code contained bugs. The other reason is that it is the upstream
authros/maintainers decision how the cases should be split up, the patch can
only make a suggestion how this can be done. So, the patch has enough
information for the maintainers to make a decision about it, it has some
working code that works on our platform, and it is conservative as it keeps
it the same for all other platforms that it run on before.
The authors and maintainers can (and should!) make a decision on how the
patch is integrated best into the official version. Eliminating the static
case and using dynamic allocation always is one way this can be done (and it
would be my personal suggestion, too).
Without the patch or an equivalent one, pam will not compile on the Hurd,
which is a step backward.
If the purpose of your mail was to get someone verufy the patch for
correctness on other platforms, then please make this clear in your reply.
I don't have time to proof read it right now, but what sticks out is that
getline is only available in the GNU C library, so that is a potential
incompatibility. An autoconf check and a replacement function in a helper
library could fix this.
Thanks!
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
--
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: