LJ2SYWIPHSNC49lmO1Bd4hGDAvT8lm-I4heOGrtdZPIRcDoOw2e9P4YxtKT_72r1Qwm3UfnpkCJqtM1UBkfkCw
----- END CREV PROOF -----
+----- BEGIN CREV PROOF -----
+kind: package review
+version: -1
+date: "2022-01-08T02:06:31.277120223+11:00"
+from:
+ id-type: crev
+ id: QE5OVlHZ4QyOcMqdjXhS1MgsoZHvUqxOHNZwyfpsDIU
+ url: "https://git.chrismorgan.info/crev-proofs"
+package:
+ source: "https://crates.io"
+ name: sanitise-file-name
+ version: 1.0.0
+ revision: 2f75e28d1f5d097ae5931fd05dd1b4fe39ec8c08
+ digest: egqrezU_0kaH9V4t1GOLIZe9W2aKoGc-isplQ-9l3d0
+review:
+ thoroughness: high
+ understanding: high
+ rating: strong
+comment: |-
+ I wrote this crate, with great care. (Sometimes it needed it!)
+
+ It has unfortunately ended up with rather a lot of code, but a fair bit of
+ that is related to Doing Things Right. The calculating of *exactly* how many
+ bytes may be needed is painfully involved (again a part of Doing Things
+ Right, especially as regards extension cleverness), but I’ve reviewed it
+ multiple times on different days and each time convinced myself that it is in
+ fact correct.
+
+ I believe that there are only two ways of causing this to panic, both easily
+ avoided by following instructions, and otherwise harmless. Firstly, giving
+ `sanitise_to` a `tinyvec_string::ArrayString` that doesn’t have enough space
+ remaining. That’s definite careless user error: `max_alloc_size_const` was
+ right there and clearly identified in the docs with explanation about the
+ whys and wherefores. Secondly, a slight variant of that: implementing
+ `Stringy` on some other type in a panicky fashion.
+
+ (Writing this review led me to add a mention of the possible panic to
+ sanitise_to’s docs, but I don’t think it warrants a 1.0.1 release.)
+----- SIGN CREV PROOF -----
+ymZLNHdzGamyaPo5JyBuSNUY398pyzpjsFMsup1knXtscSZumHP3ZgzNC8KPO7VCQ-23XnQxapenIX27x_DdDw
+----- END CREV PROOF -----
+