InputStream Library handles memory in a strange way

[Cosmodude]

https://github.com/sushiswap/sushiswap/blob/0ae71ae24a681fe4253fa9ba14dc7185581291cd/protocols/route-processor/contracts/InputStream.sol

Please address these risks/issues:

1. Memory Layout Misunderstandings: The methods for reading data types (readUint8, readUint16, etc.) seem to misunderstand how Solidity handles memory. They attempt to read data directly from subsequent memory locations without proper handling for data alignment or considering the actual size of the stored values.

2. Data Extraction Issues: The functions increment the stream position by the size of the data type they intend to read (1 for uint8, 2 for uint16, etc.) but then use mload to load 32 bytes of data from that position. This approach does not correctly extract smaller data types from within the 32-byte word that Solidity uses for memory operations.

3. Potential for Data Overlap and Misalignment: Because Ethereum's EVM operates with 32-byte words, reading values like uint8, uint16, etc., directly via mload without masking or shifting operations can lead to incorrect values being read or potential data overlap, especially without proper alignment adjustments.

[Cosmodude]

Example of issues:

Correct Data Extraction:
When reading smaller data types (like uint8, uint16, uint24, etc.), you should only extract the relevant portion of the 32-byte word. This typically involves masking out irrelevant bits and possibly shifting the bits to the right position. For example, to correctly read a uint8 value:
res := and(mload(pos), 0xFF)
Additionally, the stream's position should be updated before reading the value to ensure alignment with the start of the data, not after.

[Okavango]

Thank you for your concern!

InputStream works with compact serialized data and doesn't need data alignment or padding zeros
EVM has correct internal type castings. If you cast uint256 to uint8 for example then all high bits are set to zero.

Example: https://github.com/sushiswap/sushiswap/blob/0ae71ae24a681fe4253fa9ba14dc7185581291cd/protocols/route-processor/contracts/InputStream.sol#L37

It works correct and was very good tested. And Audited