[19073] in Kerberos_V5_Development
Re: Questions about iter check in profile_iterator()
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jan 14 13:09:22 2015
Message-ID: <54B6B0C3.4010108@mit.edu>
Date: Wed, 14 Jan 2015 13:09:07 -0500
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Shawn M Emery <shawn.emery@oracle.com>, krbdev@mit.edu
In-Reply-To: <54B4BF20.1080203@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 01/13/2015 01:45 AM, Shawn M Emery wrote:
> We may want to change other functions like krb5_425_conv_principal if
> this is the intended conditional.
I need to amend my previous answer on this.
When the iteration has finished, profile_iterator() returns 0 with
*iter_p, *ret_name, and *ret_value all set to NULL.
krb5_425_conv_principal() detects this at line 290 and breaks out of the
loop. The code quoted in this post's original thread doesn't do that,
instead continuing on to call profile_iterator() once again with a null
*iter_p.
I don't think a change to krb5_425_conv_principal() is warranted. There
are several ways to correctly terminate a profile iteration loop and it
uses one of them. If I were writing an iteration loop myself, I would
probably write:
for (;;) {
ret = profile_iterator(&state, &name, &value);
if (ret)
goto cleanup; /* ... or otherwise handle the error */
if (name == NULL)
break;
/* Do stuff with name and value. */
profile_release_string(name);
profile_release_string(value);
}
I will submit a pull request to restore the 1.9 behavior of
profile_iterator() on a null *iter_p, but correct calling code should
not be relying on that behavior.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
