On 10-08-17 04:11 AM, Peter Hull wrote:
I believe that CoreFoundation has 'magic refcounts' for read-only data
(for example literal strings declared with CFSTR) These objects have
a certain (large) value for their refcount which retain/release check
- if it equals the magic number they don't do anything. Would that be
useful?
Yeah. The most-obvious way is to steal (unsigned)-1 or something as the
"I'm a constant" refcount, and do double-checking of that.
However, our existing slot-evolution scheme has to null-set and
null-check box pointers before twiddling refcounts anyways; adding a
magic-refcount-check would make for More Checks. I'd be amenable to a
Same Number Of Checks, More Cleverness scheme that tries to combine the
null check with the const-ness check (say, tag the *pointers* rather
than picking magic refcounts, and make the pointers to constants have
tag=0), because whatever cost happens here will be quite heavily
replicated throughout resulting programs.
A fair bit of this is implementation-specific. We could do N different
things, just need to be sure *one* of them can be done relatively
efficiently.
Is it possible to create a hash (SHA1 or whatever) from just the
'interface' bit of a crate?
Yeah. When I said CHF-identity this is what I meant. Cryptographic Hash
Function. Sorry for being opaque.
To elaborate on the idea: CHFs have wonderful properties but a few
displeasing ones. I have ... a bit of history with this argument :)
Pros:
- Changing even the smallest little detail is likely to be caught.
- O(1) checking of identity with delightful deep compositionality.
- Easy to produce, say, 2 or 3 different modes of comparison:
- CHF-of-names-and-types
- CHF-of-names-and-types-and-constant-values
- CHF-of-names-and-types-and-all-implementation-source-code
- CHF-of-entire-text-of-compilation-unit-and-build-env
(Yes, there are probably a few users out there who want the latter.
People doing high-integrity stuff who need to re-test everything and
archive everything any time a single bit on the target system changes..)
Cons:
- Identity is, strictly speaking, probabilistic. You will have some
users out there who complain bitterly about the possibility of
either accidental collision (astronomical odds) or malicious attacks
when the hash inevitably weakens (it's not a security system, but
users will treat it as such, Now You Have Two Problems)
- Tokens are un-ordered. If you want to say one version is "newer"
than another, you are SOL. Need to maintain external metadata.
- Possibly more unstable than you want: sometimes a 'trivial' change
winds up causing a CHF perturbation / incompatibility. You have more
leeway defining partial orders or equivalence classes via recursive
comparisons. Equality case can sometimes be mitigated by
normalization passes.
There are various combinations, of course. UUIDs + CHFs get you over con
#1. Metadata tags + UUIDs + CHFs get you over 1 and 2... I'm willing to
fiddle with this a fair bit to get it maximally useful. Existing linkage
and tooling schemes are often really bad and make life miserable for
everyone (end-users, packagers, developers, sysadmins, support
engineers, ...)
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
