Open simonjbeaumont opened 5 months ago
I'm not wild about adding a retroactive conformance: we don't have a unique privilege to add this conformance. Can I suggest instead we add a different overload without a conformance?
So, I've had this kicking around on my machine as an executable target, called crypto-errno
. Do you think that'd be a better way to have this information provided for development and, if so, worth having in the repo?
We could do both.
Motivation
When an error occurs in a BoringSSL call, we typically embed the packed error code in a
CryptoKitError.underlyingCoreCryptoError(error: Int32)
. This packed error code consists of the library and the reason and BoringSSL has functions for unpacking these and getting descriptive messages for them. I often spend my time in a debugger, manually calling these C functions and then looking things up in header files.Modifications
In
_CryptoExtras
(not inCrypto
) add a (possibly retroactive) conformance toCustomStringConvertible
.Result
If
_CryptoExtras
is imported, errors will likely be much more informative. For example,