KCoreaddons build failiure on ARM

[David Faure]

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?
OK, this is just about signed/unsigned, not about really wider.
So yeah the bug is that glibc should use unsigned int there instead,
but the issue you mention "the comparison will fail" might not happen, if the 
comparison uses the right signedness. There is no truncation happening, at 
least.

A static_cast<unsigned int> workaround in kcoreaddons would work in practice, 
no?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5