On Sun, Aug 19, 2012 at 06:53:37PM +0200, Dan Luedtke wrote: > > * minor point, but endianness-flipping in place is *the* way to get > > hard-to-catch endianness bugs. foo = cpu_to_le64(foo) is a bloody bad idea; > > either use object for host-endian all along, or use it only for (in your > > case) little-endian. > I am not sure I understood this right. > At what point should I convert e.g. the file size (little endian 64bit > value stored on disk) to host endianess? When filling the inode? > Is inode->i_size = le64_to_cpu(size) bad, too? Conversions *in* *place* are bad. The above is fine if you have 'size' variable used only for little-endian values (and declare it __le64, then). The thing is, thinking of endianness conversions as architecture-conditional byteswaps is wrong. Treat them as you would treat dealing with some encoding; that's the reason why we have separate le64_to_cpu() and cpu_to_le64(), even though they are identical as functions - on all architectures we support. And don't use the same variable for both the host- and fixed-endian values; it's far too easy to get confused on code modifications and get the situation when two code paths lead to the same point, one with host-endian value in that variable and another with fixed-endian. Real fun to debug, especially when one of the codepaths is rarely taken... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
