Fix latest round of clippy lints

[aldanor]

@mulimoen Thanks for taking care of all this - many lints actually make sense - e.g. there was some old code that couldn't use [T; N] deriving Clone for all N so we had to do it manually, etc.

There's a few things I've pointed out that are questionable:

• must-use
• map-or, map-or-else that, in my opinion, hurt readability in our particular use cases
• what's with align checks, which lint is it? (especially when casting to byte pointers)

[mulimoen]

Thanks @aldanor for reviewing this. Align checks are for casting to pointer-to-pointer, e.g. error: casting from *mut u8 to a more-strictly-aligned pointer (*mut *const u8) (1 < 8 bytes). Could be I have misunderstood some of this code, quite a lot of tricky pointer logic there.

[aldanor]

Given that we allocate memory either via libc::malloc, whose man states:

The malloc() and calloc() functions return a pointer to the allocated memory that is suitably aligned for any kind of variable.

Or via H5allocate_memory:

• which calls H5MM_malloc
  • which either calls HDmalloc
  • which is defined as alias for malloc => all good, no checks needed
  • or uses its own linked-list block allocator
  • which allocates an H5MM_block_t block via HDmalloc (so blocks are 8-byte aligned at the very least)
  • each block has a header of H5MM_HEAD_GUARD_SIZE = 8, so each block start is 8-byte aligned
  • inside the block itself, buffer is also 8-byte aligned as there's a specific dummy field inside a union to ensure that:

    double _align; /* Align following buffer (b) to double boundary (unused) */

  • so, buffer start is 8-byte aligned at the very least

=> in whichever case, 8-byte alignment is pretty much guaranteed and we don't need to check it ourselves?

[mulimoen]

That is some great detective work @aldanor! I would also not expect to see any alignment issues as allocations in C tends to be very conservative, so it's great that we can remove these checks

[aldanor]

Great, thanks!