From: Joseph Myers <joseph@codesourcery.com>
To: Alistair Francis <alistair.francis@wdc.com>
Cc: <libc-alpha@sourceware.org>, <alistair23@gmaill.com>
Subject: Re: [PATCH v6 2/2] Define __STATFS_MATCHES_STATFS64
Date: Tue, 22 Oct 2019 22:33:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.21.1910222229230.27117@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20191022155921.8697-2-alistair.francis@wdc.com>
On Tue, 22 Oct 2019, Alistair Francis wrote:
> On a 32-bit platform with a 64-bit ino_t type (__STATFS_MATCHES_STATFS64
> == 1)
The commit message should not talk about ino_t; the types in this
structure are nothing to do with ino_t, even if in fact it happens that
they do match.
> diff --git a/sysdeps/mach/hurd/bits/typesizes.h b/sysdeps/mach/hurd/bits/typesizes.h
> index c30de12d1d4..e4c975ebd07 100644
> --- a/sysdeps/mach/hurd/bits/typesizes.h
> +++ b/sysdeps/mach/hurd/bits/typesizes.h
> @@ -64,5 +64,11 @@
> /* Number of descriptors that can fit in an `fd_set'. */
> #define __FD_SETSIZE 256
>
> +/* Tell the libc code that fsblkcnt_t, fsblkcnt64_t, fsfilcnt_t and
> + fsfilcnt64_t are actually the same type for all ABI purposes, even
> + if possibly expressed as different base types for C type-checking
> + purposes. */
> +# define __STATFS_MATCHES_STATFS64 1
I don't believe that's accurate. __FSBLKCNT_T_TYPE is __ULONGWORD_TYPE
but __FSBLKCNT64_T_TYPE is __UQUAD_TYPE, for example (and the only
existing Hurd port is 32-bit, so the types never match for Hurd at
present, so an unconditional 0 would be OK for the definition there right
now).
> diff --git a/sysdeps/unix/sysv/linux/alpha/bits/typesizes.h b/sysdeps/unix/sysv/linux/alpha/bits/typesizes.h
> index 20231152e33..5eb96f9a1e7 100644
> --- a/sysdeps/unix/sysv/linux/alpha/bits/typesizes.h
> +++ b/sysdeps/unix/sysv/linux/alpha/bits/typesizes.h
> @@ -69,6 +69,9 @@
> /* And for __rlim_t and __rlim64_t. */
> #define __RLIM_T_MATCHES_RLIM64_T 1
>
> +/* And for fsblkcnt_t, fsblkcnt64_t, fsfilcnt_t and fsfilcnt64_t. */
> +# define __STATFS_MATCHES_STATFS64 1
This is also inaccurate; alpha, despite being a 64-bit architecture, uses
a 32-bit statfs by default.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2019-10-22 22:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-22 16:04 [PATCH v6 1/2] sysdeps/stat: Handle 64-bit ino_t types on 32-bit hosts Alistair Francis
2019-10-22 16:04 ` [PATCH v6 2/2] Define __STATFS_MATCHES_STATFS64 Alistair Francis
2019-10-22 22:33 ` Joseph Myers [this message]
2019-10-22 22:42 ` Alistair Francis
2019-10-22 22:28 ` [PATCH v6 1/2] sysdeps/stat: Handle 64-bit ino_t types on 32-bit hosts Joseph Myers
2019-10-22 22:40 ` Alistair Francis
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=alpine.DEB.2.21.1910222229230.27117@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmaill.com \
--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).