[436] in Kerberos-V5-bugs
Re: "flags" argument should not have been added to krb5_recvauth
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon Mar 7 22:01:42 1994
Date: Mon, 7 Mar 94 22:01:31 EST
From: tytso@MIT.EDU (Theodore Ts'o)
To: "Jonathan I. Kamens" <jik@security.ov.com>
Cc: krb5-bugs@MIT.EDU
In-Reply-To: Jonathan I. Kamens's message of Mon, 7 Mar 1994 18:25:25 -0500,
Date: Mon, 7 Mar 1994 18:25:25 -0500
From: "Jonathan I. Kamens" <jik@security.ov.com>
Beta 3 added a "flags" argument to the krb5_recvauth function
that the function didn't have in beta 2. I can't see any reason at
all to make a backward-incompatible change like this, especially
since, as src/doc/api/krb5.tex says, "For non-library callers,
\funcparam{flags} should be 0." It would have been much, much better
to add a function like krb5_recvauth_internal to the library, and make
krb5_recvauth call it with a flags value of 0 and return the result.
I think this should be fixed in the way I describe, even
though it means making yet another backward-incompatible change,
because it makes no sense to put an argument that people "just
shouldn't use" in a visible function.
I considered doing exactly what you propose. However, I decided that
there was a chance that some point in the future, there might be a need
for non-library callers to have access to a "flags" argument to control
the behavior of recvauth(). So, in the interest of future
expandability, I added the flags argument directly to recvauth().
Adding a flags argument shouldn't be all that onerous to fix; I consider
it fair game while the software is still in Beta release.
In contrast, the changes make the memory allocation strategies
consistent probably will be much harder to deal with, even though they
didn't make any explicit change to the function parameters.
- Ted
