btrfs_extref_hash 64-bit vs. btrfs_crc32c 32-bit

btrfs_extref_hash 64-bit vs. btrfs_crc32c 32-bit

[Hans van Kranenburg]

Hi,

When looking around in the kernel code, I ran into this (hash.h):

u32 btrfs_crc32c(u32 crc, const void *address, unsigned int length);

[...]

static inline u64 btrfs_extref_hash(u64 parent_objectid, const char *name,
int len)
{
return (u64) btrfs_crc32c(parent_objectid, name, len);
}

[...]

What is the "official" behaviour of just stuffing a 64-bit
(parent_objectid) value into a 32-bit function argument (crc)? Does it
get truncated? Does this compile without a warning?

I would expect that the caller should do the housekeeping of deciding
how to transform the 64 bit parent_objectid into some 32 bit value.

-- 
Hans van Kranenburg

Re: btrfs_extref_hash 64-bit vs. btrfs_crc32c 32-bit

[Hans van Kranenburg]

On 09/23/2017 12:35 PM, Hans van Kranenburg wrote:
> Hi,
> 
> When looking around in the kernel code, I ran into this (hash.h):
> 
> u32 btrfs_crc32c(u32 crc, const void *address, unsigned int length);
> 
> [...]
> 
> static inline u64 btrfs_extref_hash(u64 parent_objectid, const char *name,
> int len)
> {
> return (u64) btrfs_crc32c(parent_objectid, name, len);
> }
> 
> [...]
> 
> What is the "official" behaviour of just stuffing a 64-bit
> (parent_objectid) value into a 32-bit function argument (crc)? Does it
> get truncated? Does this compile without a warning?
> 
> I would expect that the caller should do the housekeeping of deciding
> how to transform the 64 bit parent_objectid into some 32 bit value.

In the meantime I can of course answer this myself...

#include <stdlib.h>
#include <stdio.h>

typedef unsigned int __u32;
typedef unsigned long __u64;

void i_eat_32_for_breakfast(__u32 food) {
	printf("%u\n", food);
}

int main(void) {
	__u64 eat_this = 4294968320;
	i_eat_32_for_breakfast(eat_this);
	return 0;
}

-$ ./breakfast
1024

-- 
Hans van Kranenburg