This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/4] Consolidate pread/pread64 implementations
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot com>
- Date: Fri, 8 Jan 2016 18:02:23 +0000
- Subject: Re: [PATCH 3/4] Consolidate pread/pread64 implementations
- Authentication-results: sourceware.org; auth=none
- References: <1452187108-6504-1-git-send-email-adhemerval dot zanella at linaro dot org> <1452187108-6504-4-git-send-email-adhemerval dot zanella at linaro dot org> <20160107195245 dot GB25548 at vapier dot lan> <568ECAEE dot 9020602 at linaro dot org> <20160107205418 dot GE25548 at vapier dot lan> <568ED2AD dot 3000109 at linaro dot org> <568FB8D8 dot 8090802 at linaro dot org>
On Fri, 8 Jan 2016, Adhemerval Zanella wrote:
> Ok I got a better solution to avoid code build duplication. The only
> issue is for mips64 n32, sizeof(off_t) is different than sizeof(off64_t)
> which leaded to continue provide a mips pread implementation (although
> as for sh is uses de default one).
To be clear: that separate n32 implementation should only be needed
because pread and pread64 have incompatible types (without some #define
hacks to hide one of the header declarations). The pread64 implementation
(defined to take a 64-bit function argument) should be usable for pread as
well, because both 32-bit and 64-bit arguments are passed in a single
register, and 32-bit integer arguments are always sign-extended to 64-bit
(even if of an unsigned type) when passed in registers. (It would have to
be that way round; a pread implementation would not be safe to use for
pread64 in case the compiler generated code that assumed the register had
a 32-bit off_t value.)
--
Joseph S. Myers
joseph@codesourcery.com