On Mon, June 22, 2015 12:18:27 David Faure wrote: > On Sunday 21 June 2015 15:04:58 Michael Pyne wrote: > > On Fri, June 19, 2015 20:40:39 Rohan Garg wrote: > > > Hi > > > I'm trying to compile kcoreaddons on ARM with clang and I'm hitting > > > this build failiure : > > > > > > 06:22:27 ../../../src/lib/io/kfilesystemtype.cpp:112:10: error: case > > > value evaluates to 2240043254, which cannot be narrowed to type > > > '__fsword_t' (aka 'int') [-Wc++11-narrowing] > > > 06:22:27 case RAMFS_MAGIC: > > > 06:22:27 ^ > > > 06:22:28 ../../../src/lib/io/kfilesystemtype.cpp:89:32: note: expanded > > > from macro 'RAMFS_MAGIC' > > > 06:22:28 # define RAMFS_MAGIC 0x858458F6 > > > 06:22:28 ^ > > > 06:22:28 1 error generated. > > > > > > Could someone take a look at it? > > > > > > The full build log is here [1] > > > > Hi, > > > > It seems that the `int' type for the ABI you're compiling against is not > > wide enough to support the 'magic' value used to determine the fs type of > > a > > file system. > > > > But this portion of the code comes more or less from Linux directly (e.g. > > see the man page for statfs(2) to see where the magic values were obtained > > from). I'm not sure what exactly is to be done from here since the > > narrowing error occurs in Linux-specific code (being used here in a > > Linux-specific code path). > > > > We could cast the value in the switch statement to a wider type here, but > > if glibc is using the not-wide-enough int to hold the magic value then > > the value returned for RAMFS will still not fit in struct statfs (and > > therefore could not compare equal to the actual RAMFS magic). > > > > In short the real solution is for struct statfs to define their __fsword_t > > type to be wider in the first place, but we can't control that. > > I don't follow. How does 0x858458F6 not fit into an int, even on a 32 bit > machine?
That's just it, I wasn't sure the machine in question had 32-bit ints or 16- bit ints. :) A static_cast<unsigned> should work fine indeed, especially if we update both the switch test and the MAGIC_RAMFS macro to account for the 8-bit fstype Alexander described. Unless we can simply use std::make_unsigned<>... I wonder what compiler support is like for that template? Regards, - Michael Pyne _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
