help-shishi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On shishi_parse_name().


From: Simon Josefsson
Subject: Re: On shishi_parse_name().
Date: Wed, 15 Aug 2012 19:17:35 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux)

Mats Erik Andersson <address@hidden> writes:

> Hello,
>
> the manual page and all documentation of
> shishi_parse_name() are inaccurate in the
> way they fail to contain an at-sign between
> principal name and realm name in two cases.
> Also the variable referencing is in error.
> The following patch suggestion might mend
> this, but I have not really executed the
> parsers on the change, though.

I have applied the patch, thank you.

> The API call shishi_parse_name() is notable
> on two more accounts:
>
>  * The Shishi handle is part of the signature,
>    but it is never used,

Yes, this was intentional so that if something from the handle will ever
be needed in the future, we can use it.

>  so the expected call shishi_error() is reporting irrelevant text when
>  called after a failure in shishi_parse_name().  Can an error
>  condition in shishi_parse_name() be inserted into the handle's
>  context?

I've added some shishi_error_printf, what do you think?

>  * There is an asymmetry in the return values
>    `*principal' and `*realm', since the former
>    always is allocated, while the latter need
>    not be so. Would it be disruptive to return
>    `*principal' as NULL when the component is
>    missing? I have good use of the call
>
>       shishi_parse_name(&h, "@EX.ORG", &principal, &realm)
>
>    which displays asymmetry in relation to
>
>       shishi_parse_name(&h, "me/admin", &principal, &realm)
>
>    since `realm = "EX.ORG"' and `principal = ""' in the first
>    case, and `principal' must be deallocated afterwards.
>    In contrast, the second case has `realm = NULL'.

I think this is fine, patches welcome!

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]