On HP-UX it's as simple as using off64_t vs off_t when sendfile64 is used !
sbsize_t sendfile(int s, int fd, off_t offset, bsize_t nbytes,
const struct iovec *hdtrl, int flags);
vs.
sbsize64_t sendfile64(int s, int fd, off64_t offset, bsize64_t nbytes,
const struct iovec *hdtrl, int flags);
Let me know if you were looking for something else !
-Madhu
>-----Original Message-----
>From: Joe Orton [mailto:[EMAIL PROTECTED]
>Sent: Monday, March 22, 2004 5:18 AM
>To: [email protected]
>Subject: RFC: Unix LFS support for 1.0
>
>
>A concrete proposal... the two requirements are:
>
>1. APR 1.0 should support large files on Unix systems which have a
>32-bit off_t but support the LFS standard
>and
>2. APR must not export -D_FILE_OFFSET_BITS=64 by default to
>get a 64-bit
>off_t, since this breaks the ABI of any other packages which use off_t
>in their API, and is generally a Bad Thing. But users should
>be allowed
>to build like this by passing the appropriate CPPFLAGS to configure if
>they want.
>
>The proposed solution is that APR must use the "transitional"
>LFS API on
>such platforms, define apr_off_t as off64_t; and use lseek64
>and friends
>throughout. Some of this work is already done for Netware, but it
>appears to be incomplete since it doesn't use readdir{,_r}64,
>nor struct
>stat64; but maybe Netware does things differently.
>
>If anyone has issues with this approach, please speak up soon!
>
>Work in progress patch attached, todo list currently:
>
>- AIX and Solaris have variants for their sendfile interfaces
>which take
>an off64_t in the appropriate place; need to hook these up and check
>HP-UX too (### help welcome! :)
>
>- what to do about old Linux 2.2's which have no sendfile64(): disable
>sendfile support, or disable LFS support? both change the ABI
>
>- automatically add -D_LARGEFILE64_SOURCE to CPPFLAGS on
>platforms which
>need it. Linux doesn't because it's implied by -D_GNU_SOURCE, other
>platforms do.
>
>
>
