[1231] in Release_7.7_team
!@%&$&(% libacl.a (aka acl_files.c)
daemon@ATHENA.MIT.EDU (Albert Dvornik)
Fri Mar 13 02:52:49 1998
To: release-team@MIT.EDU
From: Albert Dvornik <bert@MIT.EDU>
Date: Fri, 13 Mar 1998 02:52:42 EST
[1] acl_files.c is an ancient, poorly maintained, divergent piece of debris.
[2] A part of the reason of why I'm not happy with this code is the
fact that there are TWO (2) copies of this in the OLC source tree,
which is frustrating to deal with on top of all the other junk.
However, there are settings of limits that OLC wants different
from current libacl.a, and no way to set them, so there is no good
way to make OLC use libacl.a as it now exists.
[3] I doubt some of the functionality EVER worked. (Of course, one
may never know, since there's basically NO error checking.)
For example, as far as I can tell, the file-descriptor hashing has
not worked since October 1989, when a line was added to close each
file whenever data was loaded from it. Ironically, the rlog for
this change (athena/lib/acl/acl_files.c:1.5) states:
File descriptor leak fixed in acl_load().
In general, my confidence that any part of acl_files.c is
fully functional is rather small right now. (I mean any of the
copies of acl_files.c, whether in libacl.a or elsewhere.)
Given the above things, I would like to very strongly propose that we
rewrite libacl.a from scratch, keeping all interfaces as described in
acl_files.doc, but adding a way to configure most of the preset
limits. I'm not at all convinced that the old code should be looked
at at all, except as an addition to the interface spec.
Please? Pretty please? Really pretty please?
--bert
