ObjFW  History of src/OFSecureData.m of 16aab59c3c36d805c08aa9483dfe2fa3ad3b32c081f019ccd9b26f5473dc4788

This should be more efficient on some architectures.

As a nice side effect, this is also what Linux does in some userspace
APIs, so after this change, these macros can be used for this as well
(and Linux interestingly does not provide similar macros in the
userspace headers). file: [d0c4634748] check-in: [96f946d7ad] user: js, branch: trunk, size: 15198 [annotate] [blame] [check-ins using] [diff]

While the idea sounds nice that the tag name is the class, this means the
serialization includes whether something is mutable or immutable. This means
doing as much as making something immutable changes the serialization, which
can then cause issues after being deserialized. file: [47b9727f66] check-in: [6ce0093f8d] user: js, branch: trunk, size: 14585 [annotate] [blame] [check-ins using] [diff]

errno is problematic for Amiga libraries and is also not thread-safe on
some systems, even though it should. file: [a977d1a98b] check-in: [5b37fbeb82] user: js, branch: trunk, size: 14836 [annotate] [blame] [check-ins using] [diff]

The new names should be more accurate. file: [960649af1d] check-in: [627511b032] user: js, branch: trunk, size: 14715 [annotate] [blame] [check-ins using] [diff]

While it makes sense to wrap malloc and calloc to replace the error
checking with exceptions, it does not make sense to wrap free. file: [de9178b4e4] check-in: [3d8286feee] user: js, branch: trunk, size: 14705 [annotate] [blame] [check-ins using] [diff]

With this property, it's possible to specify whether the memory should
be protected from swapping or not. This makes it easier for e.g. the
crypto hash classes: They can now just always use OFSecureData without
wasting unswappable memory if it's not needed. file: [800160da50] check-in: [e629dc83a9] user: js, branch: trunk, size: 14543 [annotate] [blame] [check-ins using] [diff]

The reason for this change is that whether non-swappable memory can be
allocated or not is something that changes over time, so calling
+[isSecure] always had a potential for a race. The only reliable way is
to allocate the memory and then report whether it's swappable or not.

It's also called -[isSwappable] now to be more precise. file: [0b2ff22574] check-in: [60caadeb5d] user: js, branch: trunk, size: 12950 [annotate] [blame] [check-ins using] [diff]

This allows the runtime to only link against the parts it needs, without
pulling in unnecessary parts like thread spawning, TLS and conditions. file: [fa28a56f57] check-in: [5358e9ea6a] user: js, branch: trunk, size: 13442 [annotate] [blame] [check-ins using] [diff]

This is useful to allocate secure memory before enabling a sandbox that
does not allow it anymore. file: [520efa2118] check-in: [0487a81ced] user: js, branch: trunk, size: 13249 [annotate] [blame] [check-ins using] [diff]

This avoids having at last one page per OFSecureData and allows multiple
small OFSecureData sharing the same page, which is important on systems
where the number of pages that can be locked is very limited. file: [43dbd361d6] check-in: [0e45b7bb1c] user: js, branch: trunk, size: 10038 [annotate] [blame] [check-ins using] [diff]