"Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > On Sat, Jan 19, 2008 at 07:09:31PM +0100, Jim Meyering wrote: >> "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list