On Tue, May 22, 2012 at 10:24:59AM -0500, Eric Sandeen wrote: > > How do you decide between using "unsigned long long" and "blk64_t" below? > Consistency more than anything else. At least at one point e2fsck/recovery.c was supposed to be identical to the kernel's fs/jbd2/recovery.c, and so that meant we tried to use avoid using both kernel-specific idioms that would be hard to replicate in userspace (but we do quite a bit of that; see e2fsck/jfs_user.h) as well as userspace-specific idioms/typedefs that don't work well in the kernel context. Over time the two have drifted apart, and a good future project would be to try to bring them closer together so that bugs in one are more likely to be correctly fixed in the other. The other headache is with %llu in printf strings. One of the problems with using blk64_t is that we don't know whether it's an unsigned int or an unsigned long or an unsigned long long, and that causes all sorts of warnings with respect to printf format strings. We *can* fix it via a cast to an unsigned long long and using %llu, but it makes the code quite ugly. So it's a bit simpler to use %llu and just use unsigned long long, since we don't support any platform where long long is 128 bits, and on pretty much all Linux systems, long long is pretty consistently 64 bits. I wouldn't do this on anything that was an on-disk representation, of course, but in this case I figured it was easier just to use an "unsigned long long" in the struct buffer_head in jfs_user.h, and then I made everything consistent with that. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
