Fix handling empty AllowedMechanisms attribute

[Jakuje]

As returned by SoftHSM: softhsm/SoftHSMv2#825

Fixes: #323

[Jakuje]

OTOH this could be considered a softhsm bug (or at least oddness) and as a rust-cryptoki, we might want to shield a users from such pkcs11-module-specific issues. But then we would have to filter this out early in get_attributes, which does not sound great either.

[nwalfield]

You already pointed out that at least two attributes can definitely be zero length. It thus seems like a bug in rust-cryptoki that it tries to allocate 0 bytes and expects to get a pointer that can be cast to a raw pointer and passed to std::slice::from_raw_parts:

Behavior is undefined if any of the following conditions are violated:

    data must be non-null, valid for reads for len * size_of::<T>() many bytes, and it must be properly aligned

[wiktor-k]

You already pointed out that at least two attributes can definitely be zero length. It thus seems like a bug in rust-cryptoki that it tries to allocate 0 bytes and expects to get a pointer that can be cast to a raw pointer and passed to std::slice::from_raw_parts:

Behavior is undefined if any of the following conditions are violated:

    data must be non-null, valid for reads for len * size_of::<T>() many bytes, and it must be properly aligned

Validity rules for reads explicitly point out that:

For memory accesses of size zero, every pointer is valid, including the null pointer.

I'm okay with the change here, with a bit of docs around it, since at first sight it looks like a premature optimization 🤔

[nwalfield]

You already pointed out that at least two attributes can definitely be zero length. It thus seems like a bug in rust-cryptoki that it tries to allocate 0 bytes and expects to get a pointer that can be cast to a raw pointer and passed to std::slice::from_raw_parts:

Behavior is undefined if any of the following conditions are violated:

    data must be non-null, valid for reads for len * size_of::<T>() many bytes, and it must be properly aligned

Validity rules for reads explicitly point out that:

For memory accesses of size zero, every pointer is valid, including the null pointer.

I'm okay with the change here, with a bit of docs around it, since at first sight it looks like a premature optimization 🤔

That's not the only relevant thing. From slice::from_raw_parts:

data must be non-null and aligned even for zero-length slices or slices of ZSTs.

And that's the bug that we are seeing.

[neverpanic]

Typo, rest lg2m.