[Top][All Lists]
[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