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

[Daniel P. Berrange]

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.

Since both approaches are part of POSIX large file standard I don't see
one as any more or less portable than the other. Both are supported on
Solaris. I don't know about cygwin, but that only requires the remote
driver client code at this time.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|