Jason R Thorpe <thorpej@zembu.com> writes:

> In Heimdal, cc_close does what cc_destroy does in MIT.

Yes, since you can't (or couldn't in your case) ever get hold of that
memory again, it's the same as destroy.

> Looks like cc_close is "free resources associated with my instance
> of the CC ID", and cc_destroy is "delete this CC ID completely".

In the file case it's quite obvious what they mean, close is close,
and destroy is unlink. If you can only get hold of a memory cache by
doing gen_new, it's also quite obvious that close and destroy mean the
same thing (otherwise close would leak memory). This will of course
have to change if you can resolve memory cache names.

> So, for the MCC, looks like cc_close should be a noop, cc_destroy
> should fully tear down everything, and there should be no reference
> counting.

You have to keep a stub for all other ID's that still refer to the now
destroyed piece of memory. Think of what happens when you destroy a
file cache, the data isn't there, but you can detect that. In the
memory case you can't tell that a pointer isn't pointing to anything
useful, so you have to keep the data it points to, with reference
counting. The actual credentials should be freed though.

> This is to prevent name clashes in the gen_new case.  Certainly,
> some other method could be used to ensure unique MCC names, but this
> also happens to be the way MIT did it.

No, they use mktemp, which doesn't create files, but on the otherhand
doesn't provide unique names.

> I'll look at changing this, if you think it's really that important.

You could use the pointer value as a (semi-)unique name.

/Johan