On Fri, 19 Apr 2013 13:44:53 +0200 Kay Sievers <kay@xxxxxxxx> wrote: > On Fri, Apr 19, 2013 at 1:07 PM, Martin Schwidefsky > <schwidefsky@xxxxxxxxxx> wrote: > > On Fri, 19 Apr 2013 11:56:54 +0200 > > Kay Sievers <kay@xxxxxxxx> wrote: > > > >> On Fri, Apr 19, 2013 at 10:17 AM, Heiko Carstens > >> <heiko.carstens@xxxxxxxxxx> wrote: > >> > On Thu, Apr 18, 2013 at 03:10:18PM +0200, Kay Sievers wrote: > >> > >> > I just had look into the glibc code but couldn't find any (implicit) cast > >> > from int to long. > >> > Can you give a pointer to the code in glibc where this breaks? > >> > >> On 64 bit the value for userspace is long, it's just an assignment: > >> http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/statfs64.c#l59 > > > > The copy of the statfs.h header in sysdeps/unix/sysv/linux/s390/bits/statfs.h > > says differently: > > > > #ifdef __USE_LARGEFILE64 > > struct statfs64 > > { > > int f_type; > > Oh, ok, so s390 implements different ABI than what is documented in: > man 2 statfs? > > Still, the magic values defined for f_type do never fit natively into > an int. Code needs to add explicit casts to avoid comparison warnings > of signed (int) vs. unsigned (0x9... is unsigned for the compiler), > which creates these weird problems like we see in stat(1) and probably > more tools. > > It's pretty confusing to sort out such issues in userspace, and it > would be nice if it could be fixed to work without weird casting. Well, the easiest fix seem to be to convert the "int f_type" to an "unsigned int f_type". We would still face problems if the magic values won't fit into 32 bit though. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
