Just some thoughts, instead of appending the type to the function name, the type could be provided as an argument. If the type endianness is the same as the platform, then only the length is checked to be type size aligned, otherwise swapping is also provided. There are libraries available for swapping, but it is actually trivial the only advantage from a library would be it SIMD instructions could be used.

It is also possible to have one function and parameter as type as you propose.

It can look like your implementation of processing of array/buffer of numbers. But this will be better to have separate functions.

This is straightforward
SCPI_ResultBufferUInt8(..., values, countof(values), NORMAL)
SCPI_ResultBufferInt32(..., values, countof(values), SWAPPED)
SCPI_ResultBufferFloat(..., values, countof(values), ASCII)
SCPI_ResultBufferDouble(..., values, countof(values), NORMAL)

This will consume all following parameters or only one arbitrary block with swapped UInt16 values.
SCPI_ParamBufferUInt16(..., values, countof(values), ASCII_OR_SWAPPED, &result_count, ...)

This will consume only one arbitrary block of NORMAL (big-endian) 64bit integers, no ASCII encoding allowed.
SCPI_ParamBufferInt64(..., values, countof(values), NORMAL, &result_count, ...)

For me, it sounds better SCPI_ResultArrayFloat then SCPI_ResultBufferFloat, for that purpose.

We can also officially divide SCPI_ResultArbitraryBlock into two functions - SCPI_ResultArbitraryBlockHeader and SCPI_ResultArbitraryBlockData. You can later call SCPI_ResultArbitraryBlockData more then once.

I have introduced first support in 3b99af6 for returning arrays. It is still not well tested, it is not optimal but it is first step.

I would like to introduce also reading array parameters and also unit tests for all new functions.

Result functions are now ready. They are also covered by tests.
Missing part is Parameter functions.

Array parameters are prepared but currently support only text.