KCoreaddons build failiure on ARM

[Michael Pyne]

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