diff options
author | Heiko Carstens <heiko.carstens@de.ibm.com> | 2013-04-23 08:53:44 +0200 |
---|---|---|
committer | Andreas Krebbel <krebbel@linux.vnet.ibm.com> | 2013-04-23 08:59:35 +0200 |
commit | 5c95f7b66be2e59cf26f3c29cfab7657880bd76d (patch) | |
tree | 102b46e4384a94e8acca138f920d95230775f12c /nss/nss_files | |
parent | d34c915826734cf20b189e925aac9b9f176bcd53 (diff) | |
download | glibc-5c95f7b66be2e59cf26f3c29cfab7657880bd76d.tar.gz glibc-5c95f7b66be2e59cf26f3c29cfab7657880bd76d.tar.xz glibc-5c95f7b66be2e59cf26f3c29cfab7657880bd76d.zip |
S/390: Change struct statfs[64] member types to unsigned values
Kay Sievers reported that coreutils' stat tool has a problem with s390's statfs[64] definition: > The definition of struct statfs::f_type needs a fix. s390 is the only > architecture in the kernel that uses an int and expects magic > constants lager than INT_MAX to fit into. > > A fix is needed to make Fedora boot on s390, it currently fails to do > so. Userspace does not want to add code to paper-over this issue. [...] > Even coreutils cannot handle it: > #define RAMFS_MAGIC 0x858458f6 > # stat -f -c%t / > ffffffff858458f6 > > #define BTRFS_SUPER_MAGIC 0x9123683E > # stat -f -c%t /mnt > ffffffff9123683e The bug is caused by an implicit sign extension within the stat tool: out_uint_x (pformat, prefix_len, statfsbuf->f_type); where the format finally will be "%lx". A similar problem can be found in the 'tail' tool. s390 is the only architecture which has an int type f_type member in struct statfs[64]. Other architectures have either unsigned ints or long values, so that the problem doesn't occur there. Therefore change the type of the f_type member to unsigned int, so that we get zero extension instead sign extension when assignment to a long value happens. Reported-by: Kay Sievers <kay@vrfy.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Diffstat (limited to 'nss/nss_files')
0 files changed, 0 insertions, 0 deletions