Jesper Brynolf

Running with valgrind 3.15.0 and cargo-valgrind 2.1.0 actually made it worse. It crashes silently just after all the tests had been run and it was about to present the report....

just tried it with valgrind 3.19 and wiht no difference. I got no XML output.

Don't forget this one while writing the errata. https://github.com/tpm2-software/tpm2-tss/issues/1930

So it would be possible if I could bring the future to completion using another thread pool like tokio?

Thanks for the answer.

Partially fixed by #378 .

Yeah, just make everything available under structures like it already is. There is no need to provide alternative module 'paths' to the same thing for us. We do not have...

I think the reason for the nv module is because that is how it is laid out in the specification. How the code should be laid out in our source...

I agree when the native types are checked upon creation there is no point in checking them upon conversion unless you expect some cosmic radiation has caused single bit upset...

This is still needed and should perhaps be added as coding guideline. Because I still do this mistake of just using usize.