From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: libc-alpha@sourceware.org
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: [hurd,commited] hurd: Fix standard compliance of some statvfs fields
Date: Thu, 19 Apr 2018 00:07:00 -0000 [thread overview]
Message-ID: <20180419000742.19403-1-samuel.thibault@ens-lyon.org> (raw)
Standards require that the f_bsize, f_frsize, f_flag and f_namemax fields be
unsigned long. They used to be only unsigned on hurd, which happens to be
compatible with unsigned long on the only existing, 32bit, port. We can
thus merely fix the type.
* sysdeps/mach/hurd/bits/statvfs.h (struct statvfs): Make f_bsize,
f_namemax, f_frsize, and f_flag fields unsigned long int instead of
unsigned int.
(struct statvfs64): Likewise.
---
ChangeLog | 4 ++++
sysdeps/mach/hurd/bits/statvfs.h | 16 ++++++++--------
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 815c0bcaed..cd0734fbbc 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -12,6 +12,10 @@
Likewise.
* conform/data/sys/stat.h-data (stat.st_dev): Likewise.
* conform/data/sys/statvfs.h-data (statvfs.f_fsid): Likewise.
+ * sysdeps/mach/hurd/bits/statvfs.h (struct statvfs): Make f_bsize,
+ f_namemax, f_frsize, and f_flag fields unsigned long int instead of
+ unsigned int.
+ (struct statvfs64): Likewise.
2018-04-18 Joseph Myers <joseph@codesourcery.com>
diff --git a/sysdeps/mach/hurd/bits/statvfs.h b/sysdeps/mach/hurd/bits/statvfs.h
index e9624b1700..9880b2c9c7 100644
--- a/sysdeps/mach/hurd/bits/statvfs.h
+++ b/sysdeps/mach/hurd/bits/statvfs.h
@@ -30,7 +30,7 @@
struct statvfs
{
unsigned int __f_type;
- unsigned int f_bsize;
+ unsigned long int f_bsize;
#ifndef __USE_FILE_OFFSET64
__fsblkcnt_t f_blocks;
__fsblkcnt_t f_bfree;
@@ -45,14 +45,14 @@ struct statvfs
__fsfilcnt64_t f_ffree;
#endif
__fsid_t f_fsid;
- unsigned int f_namemax; /* NOTE: f_namelen in `struct statfs'. */
+ unsigned long int f_namemax; /* NOTE: f_namelen in `struct statfs'. */
#ifndef __USE_FILE_OFFSET64
__fsfilcnt_t f_favail;
#else
__fsfilcnt64_t f_favail;
#endif
- unsigned int f_frsize;
- unsigned int f_flag;
+ unsigned long int f_frsize;
+ unsigned long int f_flag;
unsigned int f_spare[3];
};
@@ -60,17 +60,17 @@ struct statvfs
struct statvfs64
{
unsigned int __f_type;
- unsigned int f_bsize;
+ unsigned long int f_bsize;
__fsblkcnt64_t f_blocks;
__fsblkcnt64_t f_bfree;
__fsblkcnt64_t f_bavail;
__fsfilcnt64_t f_files;
__fsfilcnt64_t f_ffree;
__fsid_t f_fsid;
- unsigned int f_namemax;
+ unsigned long int f_namemax;
__fsfilcnt64_t f_favail;
- unsigned int f_frsize;
- unsigned int f_flag;
+ unsigned long int f_frsize;
+ unsigned long int f_flag;
unsigned int f_spare[3];
};
#endif
--
2.15.1
reply other threads:[~2018-04-19 0:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180419000742.19403-1-samuel.thibault@ens-lyon.org \
--to=samuel.thibault@ens-lyon.org \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).