Josep Monés Teixidor wrote:
Hello Nils,
On Tue, 2006-03-21 at 20:38 +0100, Nils Larsch wrote:
SC_SUCCESS is better than 0
[....]
if the reader doesn't support this operation this function MUST
return a error like SC_ERROR_NOT_SUPPORTED (and of course applications
using this features must be able to handle this return value).
Just for the record: this patch intended to mimic sc_lock and sc_unlock
functions, which use 0 and don't return SC_ERROR_NOT_SUPPORTED if
pointer is not initialized.
the reason why I insist on this function to return an error when
the reset operation isn't supported by the reader driver is that
this function might be used to invalidate user credentials and in
this case it's important to know whether the operation succeeded
or simple did nothing.
I include your suggestions in a second try.
actually one should _never_ ignore return values ;-)
well... this actually was different than sc_lock and sc_unlock, because
these functions overwrite r if there has been an error because they
assign sc_unlock result to it (which looks like a bug to me).
I don't believe on such maximalisms, but if you really need
this is a security library, we can't be pedantic enough :)
sc_mutex_unlock's error, then i think it's better to return reset error
if both fail (which will be more explanatory). Do you agree?
yep, although a better solution would be have a (thread specific)
error stack ... I guess this should be implemented in 0.12
It should be mentioned that this function is not always implemented
(depending on the used reader driver used).
I hope someone who interfaces a reader using CT-API or OpenCT will be willing
to add this for those backends ;)
I've included a comment following your suggestion in the meanwhile.
I hope you like this second try.
slightly modified and applied. Please test a recent snapshot.
Cheers,
Nils
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
