Re: largefile64 on ports

[Greg Troxel]

What does POSIX say about all of this?  My quick reaction is that this
is all rather messy.

Is there any good reason to just not use the 64-bit calls all the time
if they exist?

On NetBSD, lseek(2) is said to be POSIX compliant:

  LIBRARY
       Standard C Library (libc, -lc)

  SYNOPSIS
       #include <unistd.h>

       off_t
       lseek(int fildes, off_t offset, int whence);

  STANDARDS
       The lseek() function conforms to ISO/IEC 9945-1:1990 (``POSIX.1'').

And off_t is __int64_t.  (It used to be 32 long long ago in 4.3BSD,
and there is binary compatability for the old syscall #.)

What does Solaris do?  I looked on the web and couldn't figure out if
one has to use different calls or if they've just changed off_t to 64
bits.

Is _LARGEFILE64 a glibc/Linux thing, or is it broader than that?  Are
there any relevant standards?

After looking, I'd say that

  the code should work ok on systems with 64-bit off_t

  because it's reasonable for systems to just have 64-bit off_t (and
  I'd argue preferable; Solaris and glibc docs seem to agree), the
  whole mess of having separate system calls should not be exported to
  guile users.

So, I'd say that via configure one should find the large calls if they
exist, and #define open_large to them, or to open if not present,
etc. and then have all the rest of the code just live with 64-bit
off_t (which I realize may be off64_t on some systems).

But now I realize the point is about the C interface labeled SCM_, and
I see why this is much harder.

I see in ports.c that _LARGEFILE64_SOURCE is defined.  As far as I can
tell, this is a glib thing rather than a standard thing and thus
should be ifdefed.  Another approach would be to tell the C library to
use the 64-bit types instead of the dual-function transitional
approach, but I suppose that impacts programs that include a guile .h
but do other things.

I don't follow SCM_HAVE_LARGEFILE64; grepping for it in CVS comes up
empty.

The two competing goals are keeping source and binary compatibility
nad having a clean interface.
The scheme way is to just have a function that takes a number, so the
SCM api should follow that as far as it can.

Perhaps we can define scm_off_t as uint64_t, and just have scm_foo
calls that use that only 64 bits.  Or both, and deprecate the old
ones.  There should be only one right way to right code that uses the
SCM_API, and that way should use 64-bit offsets always, with the other
ways marked as deprecated.

guile has a long history of compatibility trouble across upgrades,
such that worrying about ABI compat seems like a lost cause.   My view
is that if we keep ABI compat with a release series (and 1.8.0 doesn't
count), then as long as there's little API pain across series, that's
ok.

So if there's scm_off_t defined, and the calls just change to use it
(and thus become 64-bit), that seems like the best way forward.  Yes,
people have to rebuild, and they'll have to change their source
slightly, but then we have something reasonable going forward.  This
sort of change is pretty easy for users: just look for scm_off_t
defined and if so use it; if not #define scm_off_t to off_t (and be
limited to 32 bits on systems where off_t is 32 bits).  If there isn't
much code using ports from C, then this won't cause too much pain.
Exposing the 32/64 bit variants of these functions seems likely to
lead to greater long-term pain.

-- 
    Greg Troxel <address@hidden>

pgpMbnIfLu2Oc.pgp
Description: PGP signature