[Libvir] Repository for work-in-progress storage patches

[Jim Meyering]

"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.