[Libvir] Repository for work-in-progress storage patches
jim at meyering.net
Sat Jan 19 18:58:31 UTC 2008
"Daniel P. Berrange" <berrange at redhat.com> wrote:
> On Sat, Jan 19, 2008 at 07:09:31PM +0100, Jim Meyering wrote:
>> "Daniel P. Berrange" <berrange at 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.
More information about the libvir-list