This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] fallocate: pass off_t in register pair correctly for 64-bit off_t
- From: Yury Norov <ynorov at caviumnetworks dot com>
- To: <libc-alpha at sourceware dot org>, <cmetcalf at tilera dot com>, <pinskia at gmail dot com>, <cmetcalf at mellanox dot com>, <joseph at codesourcery dot com>
- Date: Fri, 24 Jun 2016 11:52:24 +0300
- Subject: Re: [PATCH] fallocate: pass off_t in register pair correctly for 64-bit off_t
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp dot mailfrom=Yuri dot Norov at caviumnetworks dot com;
- References: <1466746995-25982-1-git-send-email-ynorov at caviumnetworks dot com> <20160624083023 dot GF24532 at vapier dot lan>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Fri, Jun 24, 2016 at 04:30:23AM -0400, Mike Frysinger wrote:
> On 24 Jun 2016 08:43, Yury Norov wrote:
> > sysdeps/unix/sysv/linux/fallocate.c contains wide-spreaded hack for creating
> > register pair from 32-bit signed value:
> > LONG_LONG_PAIR (val >> 31, val)
> >
> > It works well for off_t if it is 32-bit lenght. Modern ABIs requres 64-bit off_t,
> > so this hack doesn't work for them. In this patch, fallocate handler is taken from
> > fallocate64.c, depending on __OFF_T_MATCHES_OFF64_T.
>
> what ABIs exactly are you referring to ?
AARCH64/ILP32. It would be any modern 32-bit API, as off_t should be
64-bit for them
> why is this change specific to fallocate ? seems like this argument
> could be made about any of the funcs that operate on off_t's. what
> about posix_fallocate ? posix_fadvise ?
Because it's RFC. If this one is OK, I'll prepare correct patch for
all affected functions. I also wrote this small patch to ask what way
is more preferable - with macro, or with redirection.
> > The other option to fix it is to introduce macro that creates the pair correctly
> > for both 32- and 64-bit off_t, like this:
>
> if off_t & off64_t are the same size, we don't want duplicate symbols
> that do the same thing.
> -mike
So it 1st version is OK, I'll prepare full patch with all needed
redirections.
Yury.