This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Zack Weinberg <zackw at panix dot com>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Lukasz Majewski <lukma at denx dot de>, Alistair Francis <alistair23 at gmail dot com>
- Date: Fri, 30 Aug 2019 16:36:55 +0000
- Subject: Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define
- Ironport-sdr: wpQit8HMYcNbqo9VSP3HitHHIJK7Cse9zJUGc4NYn757d3R0Df4+E8Nhk1C8uAFTgbRAu0WDlR W/9yqYeYANHBnDDi0RR9LrcxOJSP/LOXxMo5SRPstGF8HU6sN7e/l/1VvsjzG1pXdyVEVXJo2D YHdZmVIOWupv+pCszY7G720b9u3tFyxTMs5Ex+1Jy4L4+G3AG6/32tJ2PpudXYVS6zNTtsFj7D NdalpOCwCgWehxnjJOYXuTv4AJiAKGWDUor6pG311H2/XG1YXTZO6n40unP+JOMZiaJdmhrrFD cNI=
- Ironport-sdr: h5p4S27ZDJ1j2mQqZiklQHQtD0ze2tHCWh2xxUgyiDq3NQq7L0haHmX3QKTNKBFrne95G1LJB5 WcY5FFqIWs16LIyFT+iNDcoxr+7lPShGebDOrh5EJvqzOVFe0eofDXMbNKIMNlxJt90Vu+rS6k EVVzO6RYxREu1yptgwXYmRvVUbf1rOxub3UAiNN5i7Layduog7582VtifRzOV6E+EuM0gr0zwI Rv6GkHX5GTFMmi+d0ktdNuM8pThFNEXPNm3OU9NfHGpSfC2FNEplYcAsp6oI6g6iXlYSlcbHfW n2U=
- References: <20190827173015.24370-1-alistair.francis@wdc.com> <CAKCAbMiYinyQ_Gdcu94rPCm6PNw6hdq+H_dhzeADa89v2z13-A@mail.gmail.com> <alpine.DEB.2.21.1908271926030.31674@digraph.polyomino.org.uk> <20190830133818.GI9017@brightrain.aerifal.cx>
On Fri, 30 Aug 2019, Rich Felker wrote:
> To clarify, none of the timespec ones "exactly match" -- the suffixed
> syscalls on 32-bit require filling the padding around tv_nsec, whereas
What do you mean by "require filling the padding"? I thought the
conclusion in the kernel was that it dealt with zeroing the padding when
reading a timespec64 from userspace on a 32-bit system (with the caveat of
that not happening for compat tasks under 64-bit kernels before 5.1.5, and
so the question in
<https://sourceware.org/ml/libc-alpha/2019-05/msg00698.html> of whether to
treat 5.1.0 through 5.1.4 as buggy and unsupported).
--
Joseph S. Myers
joseph@codesourcery.com