[PATCH] hash: fix pointer alignment

[Radu Nicolau]

On 26-Feb-26 4:22 PM, Marat Khalili wrote:
>> diff --git a/lib/hash/rte_hash_crc.h b/lib/hash/rte_hash_crc.h
>> index fa07c97685..66f11fafcd 100644
>> --- a/lib/hash/rte_hash_crc.h
>> +++ b/lib/hash/rte_hash_crc.h
>> @@ -127,6 +127,24 @@ rte_hash_crc(const void *data, uint32_t data_len, uint32_t init_val)
>>   	unsigned i;
>>   	uintptr_t pd = (uintptr_t) data;
>>
>> +	/* align input to 8 byte boundary if needed */
>> +	if ((pd & 0x7) && data_len >= 8) {
> Perhaps the case data_len < 8 should also be included, with each of the if's below checking and correcting data_len individually?

No need to include this case; if data_len < 8 it will skip the for loop 
and fall through those 3 if's, and get processed there.


>
>> +		uintptr_t unaligned_bytes = 8 - (pd & 0x7);
>> +		data_len -= unaligned_bytes;
>> +		if (unaligned_bytes & 0x4) {
>> +			init_val = rte_hash_crc_4byte(*(const uint32_t *)pd, init_val);
>> +			pd += 4;
>> +		}
>> +		if (unaligned_bytes & 0x2) {
>> +			init_val = rte_hash_crc_2byte(*(const uint16_t *)pd, init_val);
>> +			pd += 2;
>> +		}
>> +		if (unaligned_bytes & 0x1) {
>> +			init_val = rte_hash_crc_1byte(*(const uint8_t *)pd, init_val);
>> +			pd += 1;
>> +		}
> Shouldn't the order be the opposite?
As long as we process the right number of bytes the order doesn't matter.
>
>> +	}
>> +
>>   	for (i = 0; i < data_len / 8; i++) {
>>   		init_val = rte_hash_crc_8byte(*(const uint64_t *)pd, init_val);
>>   		pd += 8;
>> --
>> 2.52.0