Re: [Libvir] Repository for work-in-progress storage patches
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Sat, Jan 19, 2008 at 07:09:31PM +0100, Jim Meyering wrote:
> "Daniel P. Berrange" <berrange(a)redhat.com> wrote:
> ...
>
> Since you're working on the weekend ;-), here are some
> notices I'd begun to accumulate:
>
> There are a bunch of new uses of open64, which isn't portable.
> How about using AC_SYS_LARGEFILE in configure.in instead?
> Then you can use "open" everywhere.
AFAIK, there are two ways to do large file suport
- Explicit support - size_t, open, etc all remain the same, and
new size64_t, open64, etc are introduced.
- Implicit support - size_t, open, etc are re-defined to be 64-bit
at all times.
Both are part of POSIX. With the latter, if any size_t is exposed in your
public API, then all applications linking against you must also be compiled
with large file suport because this is an ABI sensitive think. With the
former approach all the large file stuff is only visible inside your code
so is not leaked to applications using the lib.
Since we have size_t in the public API, AFAICT, we have no choice but to
use the explicit size64_t, open64() etc.
large-FILE support does not affect the memory-related size_t
and ssize_t types, and open64/size64_t are not specified by POSIX.
Maybe you're thinking of off_t, since that type does change size
depending on whether large-file support is enabled. But off_t is
not used in libvirt at all.