Take a stance on pointer alignment in API calls

[anrossi]

It appears MsQuic doesn't have a consistent stance on whether pointers passed into API calls are required to be aligned.
Some API calls will cast and dereference the pointer, which assumes it is aligned, while others use memcpy to handle when the pointer is unaligned.

We should either require callers to use aligned pointers (and document it) or expect callers to provide unaligned pointers and handle it appropriately.

Originally posted by @anrossi in #5376 (comment)

[guhetier]

@anrossi Can you please clarify?
I imagine you mean something like "void pointers / byte buffers passed to msquic API should be aligned in the same way than the type they are meant to receive"?

[anrossi]

Suppose the MsQuic user code looks like this,

uint8_t MyCompactData[5];
uint32_t GetLength = 2;
MsQuic->GetParam(nullptr, QUIC_PARAM_GLOBAL_RETRY_MEMORY_PERCENT, &GetLength, &MyCompactData[1]);

The pointer they're passing in to receive the parameter is not aligned. QuicLibraryGlobalParam will cast it to a uint16_t* and dereference it, which will cause a crash on ARM architectures.

MsQuic needs to document that this is not a valid usage of the API, or it needs to handle this kind of scenario.

[mtfriesen]

IMO the API caller must provide a buffer to satisfy both the size and alignment requirements of the documented I/O type. It seems fair game for MsQuic to validate the buffer pointer is aligned as required and fail the API if it is not properly aligned, because buffer sizes are validated the same way.