[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On shishi_parse_name().
From: |
Mats Erik Andersson |
Subject: |
On shishi_parse_name(). |
Date: |
Wed, 15 Aug 2012 10:32:29 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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.
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, 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?
* 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'.
Best regards,
Mats E A
docs_shishi_parse_name.diff
Description: Text Data
- On shishi_parse_name().,
Mats Erik Andersson <=