largefile64 on ports

largefile64 on ports

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

I'm looking at the addition below to allow ports to access 64-bit
files with the _LARGEFILE64 mechanism.  New scm_t_ptob_descriptor
fields seek64 and truncate64 are off64_t versions of those operations.
They're used by fports, and can also by used by an application.  The
plain seek and truncate fields are unchanged.

Extending scm_t_ptob_descriptor is a slight worry for binary
compatibility, but I think that structure is only ever created by
scm_make_port_type, so applications shouldn't be depending on its size
(only the existing fields).

Actually instantiating a port from a descriptor isn't documented, so
it's possible no applications are using the C port type stuff at all!



[-- Attachment #2: largefile.diff --]
[-- Type: text/plain, Size: 9914 bytes --]

Index: ports.h
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/ports.h,v
retrieving revision 1.98.2.2
diff -u -r1.98.2.2 ports.h
--- ports.h	30 May 2006 01:36:35 -0000	1.98.2.2
+++ ports.h	7 Sep 2006 23:06:52 -0000
@@ -184,6 +184,17 @@
   off_t (*seek) (SCM port, off_t OFFSET, int WHENCE);
   void (*truncate) (SCM port, off_t length);
 
+#if SCM_HAVE_LARGEFILE64 && defined (_LARGEFILE64_SOURCE)
+  /* if Guile has been configured with these fields, and if the user has
+     asked for off64_t stuff */
+  off64_t (*seek64) (SCM port, off64_t OFFSET, int WHENCE);
+  void (*truncate64) (SCM port, off64_t length);
+#else
+  /* otherwise dummy fields to keep the struct size constant */
+  off_t (*dummy_seek64) (SCM port, off_t OFFSET, int WHENCE);
+  void (*dummy_truncate64) (SCM port, off_t length);
+#endif
+
 } scm_t_ptob_descriptor;
 
 #define SCM_TC2PTOBNUM(x) (0x0ff & ((x) >> 8))
@@ -226,6 +237,16 @@
 SCM_API void scm_set_port_truncate (scm_t_bits tc,
 				    void (*truncate) (SCM port,
 						      off_t length));
+#if SCM_HAVE_LARGEFILE64 && defined (_LARGEFILE64_SOURCE)
+/* only give prototypes if user has asked for off64_t stuff */
+SCM_API void scm_set_port_seek64 (scm_t_bits tc,
+                                  off64_t (*seek64) (SCM port,
+                                                     off64_t OFFSET,
+                                                     int WHENCE));
+SCM_API void scm_set_port_truncate64 (scm_t_bits tc,
+                                      void (*truncate64) (SCM port,
+                                                          off64_t length));
+#endif
 SCM_API void scm_set_port_input_waiting (scm_t_bits tc, int (*input_waiting) (SCM));
 SCM_API SCM scm_char_ready_p (SCM port);
 size_t scm_take_from_input_buffers (SCM port, char *dest, size_t read_len);
Index: ports.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/ports.c,v
retrieving revision 1.204.2.6
diff -u -r1.204.2.6 ports.c
--- ports.c	1 Sep 2006 01:39:52 -0000	1.204.2.6
+++ ports.c	7 Sep 2006 23:06:56 -0000
@@ -149,6 +149,10 @@
 
       scm_ptobs[scm_numptob].seek = 0;
       scm_ptobs[scm_numptob].truncate = 0;
+#if SCM_HAVE_LARGEFILE64
+      scm_ptobs[scm_numptob].seek64 = 0;
+      scm_ptobs[scm_numptob].truncate64 = 0;
+#endif
 
       scm_numptob++;
     }
@@ -215,12 +219,30 @@
   scm_ptobs[SCM_TC2PTOBNUM (tc)].seek = seek;
 }
 
+#if SCM_HAVE_LARGEFILE64
+void
+scm_set_port_seek64 (scm_t_bits tc, off64_t (*seek64) (SCM port,
+					   off64_t OFFSET,
+					   int WHENCE))
+{
+  scm_ptobs[SCM_TC2PTOBNUM (tc)].seek64 = seek64;
+}
+#endif
+
 void
 scm_set_port_truncate (scm_t_bits tc, void (*truncate) (SCM port, off_t length))
 {
   scm_ptobs[SCM_TC2PTOBNUM (tc)].truncate = truncate;
 }
 
+#if SCM_HAVE_LARGEFILE64
+void
+scm_set_port_truncate64 (scm_t_bits tc, void (*truncate64) (SCM port, off64_t length))
+{
+  scm_ptobs[SCM_TC2PTOBNUM (tc)].truncate64 = truncate64;
+}
+#endif
+
 void
 scm_set_port_input_waiting (scm_t_bits tc, int (*input_waiting) (SCM))
 {
@@ -1385,15 +1407,25 @@
   if (SCM_OPPORTP (fd_port))
     {
       scm_t_ptob_descriptor *ptob = scm_ptobs + SCM_PTOBNUM (fd_port);
-      off_t off = scm_to_off_t (offset);
-      off_t rv;
 
-      if (!ptob->seek)
-	SCM_MISC_ERROR ("port is not seekable", 
+      if (!ptob->seek
+#if SCM_HAVE_LARGEFILE64
+          && !ptob->seek64
+#endif
+          )
+        SCM_MISC_ERROR ("port is not seekable", 
                         scm_cons (fd_port, SCM_EOL));
+
+#if SCM_HAVE_LARGEFILE64
+      if (ptob->seek64)
+        return scm_from_off64_t (ptob->seek64 (fd_port,
+                                               scm_to_off64_t (offset),
+                                               how));
       else
-	rv = ptob->seek (fd_port, off, how);
-      return scm_from_off_t (rv);
+#endif
+        return scm_from_off_t (ptob->seek (fd_port,
+                                           scm_to_off_t (offset),
+                                           how));
     }
   else /* file descriptor?.  */
     {
@@ -1457,18 +1489,27 @@
     }
   else if (SCM_OPOUTPORTP (object))
     {
-      off_t c_length = scm_to_off_t (length);
       scm_t_port *pt = SCM_PTAB_ENTRY (object);
       scm_t_ptob_descriptor *ptob = scm_ptobs + SCM_PTOBNUM (object);
       
-      if (!ptob->truncate)
+      if (!ptob->truncate
+#if SCM_HAVE_LARGEFILE64
+          && !ptob->truncate64
+#endif
+          )
 	SCM_MISC_ERROR ("port is not truncatable", SCM_EOL);
+
       if (pt->rw_active == SCM_PORT_READ)
 	scm_end_input (object);
       else if (pt->rw_active == SCM_PORT_WRITE)
 	ptob->flush (object);
       
-      ptob->truncate (object, c_length);
+#if SCM_HAVE_LARGEFILE64
+      if (ptob->truncate64)
+        ptob->truncate64 (object, scm_to_int64 (length));
+      else
+#endif
+        ptob->truncate (object, scm_to_off_t (length));
       rv = 0;
     }
   else
Index: fports.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/fports.c,v
retrieving revision 1.137.2.4
diff -u -r1.137.2.4 fports.c
--- fports.c	26 May 2006 00:24:03 -0000	1.137.2.4
+++ fports.c	7 Sep 2006 23:06:57 -0000
@@ -17,6 +17,8 @@
 
 
 \f
+#define _LARGEFILE64_SOURCE      /* ask for stat64 etc */
+
 #if HAVE_CONFIG_H
 #  include <config.h>
 #endif
@@ -46,6 +48,7 @@
 #endif
 
 #include <errno.h>
+#include <sys/types.h>
 
 #include "libguile/iselect.h"
 
@@ -57,6 +60,19 @@
 #endif /* __MINGW32__ */
 
 
+#if SIZEOF_OFF_T == SIZEOF_INT
+#define OFF_T_MAX  INT_MAX
+#define OFF_T_MIN  INT_MIN
+#elif SIZEOF_OFF_T == SIZEOF_LONG
+#define OFF_T_MAX  LONG_MAX
+#define OFF_T_MIN  LONG_MIN
+#elif SIZEOF_OFF_T == SIZEOF_LONG_LONG
+#define OFF_T_MAX  LONG_LONG_MAX
+#define OFF_T_MIN  LONG_LONG_MIN
+#else
+#error Oops, unknown OFF_T size
+#endif
+
 scm_t_bits scm_tc16_fport;
 
 
@@ -334,7 +350,7 @@
 	}
       ptr++;
     }
-  SCM_SYSCALL (fdes = open (file, flags, 0666));
+  SCM_SYSCALL (fdes = open_or_open64 (file, flags, 0666));
   if (fdes == -1)
     {
       int en = errno;
@@ -583,25 +599,39 @@
     }
 }
 
-static off_t
-fport_seek (SCM port, off_t offset, int whence)
+/* fport_seek and fport_seek64.  There's two cases here,
+
+   1. We don't have off64_t.  fport_seek_or_seek64 uses off_t and fport_seek
+      is an alias for that func.  fport_seek64 is NULL.
+
+   2. We do have off64_t.  fport_seek_or_seek64 uses off64_t and
+      fport_seek64 is an alias for that func.  An fport_seek func is created
+      as a range-checking wrapper around fport_seek64.
+
+   It'd be possible to duplicate the code of fport_seek_or_seek64, making
+   one off_t version, and one off64_t version.  But it's a bit big to want
+   to do that, hence the magic off_t or off64_t adaption.  (The truncate and
+   truncate64 funcs below are small so they can be duplicated.)  */
+
+static off_t_or_off64_t
+fport_seek_or_seek64 (SCM port, off_t_or_off64_t offset, int whence)
 {
   scm_t_port *pt = SCM_PTAB_ENTRY (port);
   scm_t_fport *fp = SCM_FSTREAM (port);
-  off_t rv;
-  off_t result;
+  off_t_or_off64_t rv;
+  off_t_or_off64_t result;
 
   if (pt->rw_active == SCM_PORT_WRITE)
     {
       if (offset != 0 || whence != SEEK_CUR)
 	{
 	  fport_flush (port);
-	  result = rv = lseek (fp->fdes, offset, whence);
+	  result = rv = lseek_or_lseek64 (fp->fdes, offset, whence);
 	}
       else
 	{
 	  /* read current position without disturbing the buffer.  */
-	  rv = lseek (fp->fdes, offset, whence);
+	  rv = lseek_or_lseek64 (fp->fdes, offset, whence);
 	  result = rv + (pt->write_pos - pt->write_buf);
 	}
     }
@@ -611,13 +641,13 @@
 	{
 	  /* could expand to avoid a second seek.  */
 	  scm_end_input (port);
-	  result = rv = lseek (fp->fdes, offset, whence);
+	  result = rv = lseek_or_lseek64 (fp->fdes, offset, whence);
 	}
       else
 	{
 	  /* read current position without disturbing the buffer
 	     (particularly the unread-char buffer).  */
-	  rv = lseek (fp->fdes, offset, whence);
+	  rv = lseek_or_lseek64 (fp->fdes, offset, whence);
 	  result = rv - (pt->read_end - pt->read_pos);
 
 	  if (pt->read_buf == pt->putback_buf)
@@ -626,7 +656,7 @@
     }
   else /* SCM_PORT_NEITHER */
     {
-      result = rv = lseek (fp->fdes, offset, whence);      
+      result = rv = lseek_or_lseek64 (fp->fdes, offset, whence);
     }
 
   if (rv == -1)
@@ -635,6 +665,25 @@
   return result;
 }
 
+#if SCM_HAVE_LARGEFILE64
+static off_t
+fport_seek (SCM port, off_t offset, int whence)
+{
+  off64_t rv = fport_seek_or_seek64 (port, (off64_t) offset, whence);
+  if (rv > OFF_T_MAX || rv < OFF_T_MIN)
+    {
+      errno = EOVERFLOW;
+      scm_syserror ("fport_seek");
+    }
+  return (off_t) rv;
+
+}
+#define fport_seek64 fport_seek_or_seek64
+#else
+#define fport_seek   fport_seek_or_seek64
+#define fport_seek64 NULL
+#endif
+
 static void
 fport_truncate (SCM port, off_t length)
 {
@@ -644,6 +693,20 @@
     scm_syserror ("ftruncate");
 }
 
+#if SCM_HAVE_LARGEFILE64
+static void
+fport_truncate64 (SCM port, off64_t length)
+{
+  scm_t_fport *fp = SCM_FSTREAM (port);
+
+  if (ftruncate64 (fp->fdes, length) == -1)
+    {
+      fprintf (stderr, "ftruncate64: %d %Ld %s\n", fp->fdes, length, strerror (errno));
+    scm_syserror ("ftruncate64");
+    }
+}
+#endif
+
 /* helper for fport_write: try to write data, using multiple system
    calls if required.  */
 #define FUNC_NAME "write_all"
@@ -851,6 +914,10 @@
   scm_set_port_close           (tc, fport_close);
   scm_set_port_seek            (tc, fport_seek);
   scm_set_port_truncate        (tc, fport_truncate);
+#if SCM_HAVE_LARGEFILE64
+  scm_set_port_seek64          (tc, fport_seek64);
+  scm_set_port_truncate64      (tc, fport_truncate64);
+#endif
   scm_set_port_input_waiting   (tc, fport_input_waiting);
 
   return tc;

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: largefile64 on ports

[Greg Troxel]

[-- Attachment #1.1: Type: text/plain, Size: 3528 bytes --]


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 <gdt@ir.bbn.com>

[-- Attachment #1.2: Type: application/pgp-signature, Size: 185 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: largefile64 on ports

[Andy Wingo]

Hi Kevin,

On Fri, 2006-09-08 at 09:17 +1000, Kevin Ryde wrote:
> Actually instantiating a port from a descriptor isn't documented, so
> it's possible no applications are using the C port type stuff at all!

Guile-gnome's gnome-vfs wrapper uses it. You can make a SCM port out of
a gnome-vfs handle and access the gnome-vfs handle associated with a
port.

I don't think that we rely on the size though -- the port is made via
scm_make_port_type, and the vmethods are set via the setters. The patch
does not look like it would cause us problems.

Regards,

Andy.
-- 
http://wingolog.org/



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: largefile64 on ports

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> writes:
>
> Is there any good reason to just not use the 64-bit calls all the time
> if they exist?

I did that for file descriptors and filenames, the ports are the
hold-out.

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

glibc has kept off_t at 32-bits, I suspect solaris is the same
(without being much worried about that system).

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

The single-unix spec

	http://www.unix.org/version2/whatsnew/lfs20mar.html

Perhaps netbsd has made that transition the default system-wide
("#define _LARGEFILE_SOURCE" in essense).

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

Exporting the 64-bit would be a bonus, letting applications on gnu
systems do 64-bit files the same as guile (will).

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

Yep, I did that for the simple bits.  "open_or_open64" and friends
are, as their names suggest, the one or the other function according
to what's available.

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

Yep, the problem is that mucking about with off_t breaks source and
binary compatibility in the port type descriptor structure seek and
truncate function fields.  If those two weren't exposed, or if they
were size_t or something, then it would have been as easy as flicking
the _LARGEFILE_SOURCE switch, as intended for most applications.

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

Should do nothing anywhere it's unrecognised or unsupported.

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

To be added in a configure test.  Another name like SCM_HAVE_OFF64_T
would be a possibility, it'd be in the public scmconfig.h.

> 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.
> ...
> Yes, people have to rebuild, and they'll have to change their source
> slightly,

That's what I'd like to avoid.  I think asking for source changes in
application code should be a last resort.  I'd probably prefer just to
make some internal changes for now if exposing the 64-bit funcs is too
controversial.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: largefile64 on ports

[Greg Troxel]

[-- Attachment #1.1: Type: text/plain, Size: 1650 bytes --]


I see your points, but it still seems really gross to impose the two
sets of calls, esp. in 2006 when the transitional API should have been
transitioned already (with simply having 64-bit off_t all the time,
and ABI compat for old programs via syscall renumbering).

I think it's important that systems with native 64-bit off_t programs
still work and don't need to do anything special.  I suppose the foo64
calls will just be the same as the regular calls, and guile can
somehow default to that.  So guile-using programs that are aware of
the foo64 method slots and those that don't should both work,
including for files of >32 bit size.   I think your patch does that;
if there are no foo64 syscalls then foo is used, and with off_t, so
things should be fine.   Am I following correctly?

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

  Should do nothing anywhere it's unrecognised or unsupported.

Probably, but still this is namespace pollution at best.
_LARGEFILE64_SOURCE doesn't show up in the SUS document you referred
me to.  (Thanks for the link; I didn't know about this before.  I
think 4.4BSD chose to just make off_t 64-bit and skip the transitional
API.  In retrospect that was clearly the right move - all this pain is
simply skipped, and old programs run fine.  But I realize that's not
the question on the table.)  So IMHO a configure test is in order for
this.  But it's not a big deal.

I don't mean to sound super cranky - thanks for making guile better.

    gdt, guile-devel standards/portability crank


[-- Attachment #1.2: Type: application/pgp-signature, Size: 185 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: largefile64 on ports

[Kevin Ryde]

Greg Troxel <gdt@ir.bbn.com> writes:
>
> it still seems really gross to impose the two
> sets of calls, esp. in 2006 when the transitional API should have been
> transitioned already ...

    "Tell him he's dreamin"
        -- Dale Kerrigan  :-)

Transition is probably do-able in a source based dist, but for
binaries it'd be bad to change the size of a basic type.  My guess
would be that it's too late and gnu/linux on 32-bit systems won't
change, leaving one to cope with the two flavours of calls.

> I think your patch does that;
> if there are no foo64 syscalls then foo is used, and with off_t, so
> things should be fine.   Am I following correctly?

Yes.  And if the 64 calls exist and are just aliases for the plain
ones, then that works too.

> _LARGEFILE64_SOURCE doesn't show up in the SUS document

Section 3.3.2 "Compilation Environment - Visibility of Transitional
API", I think.

> I
> think 4.4BSD chose to just make off_t 64-bit and skip the transitional
> API.  In retrospect that was clearly the right move - all this pain is
> simply skipped, and old programs run fine.  But I realize that's not
> the question on the table.

Yep.  I guess glibc or the linux kernel (or both, or whichever came
first) went the SVR4 way.  (I couldn't spot an off_t spec in the SRV4
ABI manuals, I suppose some of that stuff goes right back to when
seek() and friends used "long".)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: largefile64 on ports

[Kevin Ryde]

Perceiving a distinct lack of enthusiasm for extending the port
descriptor I added the 64 bits just for fports, with scm_seek and
scm_truncate calling direct to fport functions on finding that type.
Exposing the same to applications can wait for another time, perhaps
when instantiating port descriptors is actually documented.

I added this to the ports section intro:

    All file access uses the "LFS" large file support functions
    when available, so files bigger than 2 Gbytes (2^31 bytes) can
    be read and written on a 32-bit system.

I would have put a cross reference to the glibc manual on the subject,
but there doesn't seem to be a summary of what it all means there
(only individual functions).

I was tempted to mention O_LARGEFILE and how you can turn it off with
fcntl, but I'm not sure if that's too much detail.  It should only be
needed if you open an fd in guile then pass it to an external library
which is 32-bit and is so sloppy that it doesn't check error returns
from seek().


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: largefile64 on ports

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> Perceiving a distinct lack of enthusiasm for extending the port
> descriptor I added the 64 bits just for fports, with scm_seek and
> scm_truncate calling direct to fport functions on finding that type.
> Exposing the same to applications can wait for another time, perhaps
> when instantiating port descriptors is actually documented.

So file ports now use the 64-bit API when available.  By "just for
fports", I think you referred to the fact that you were initially
planning to add `64' variants of all the methods that are part of
`scm_t_ptob_descriptor', right?

OTOH, would the latter be very necessary?  Can't we just someday break
the ABI and use 64-bit types in `scm_t_ptob_descriptor'?

In any case: thanks for working on it!  ;-)

Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: largefile64 on ports

[Kevin Ryde]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
> OTOH, would the latter be very necessary?  Can't we just someday break
> the ABI and use 64-bit types in `scm_t_ptob_descriptor'?

Probably less convenient than having both.  There's likely to be
external libraries which are still 32-bit.  Zlib for instance (I
think, depending maybe on its config options).


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: largefile64 on ports

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>>
>> OTOH, would the latter be very necessary?  Can't we just someday break
>> the ABI and use 64-bit types in `scm_t_ptob_descriptor'?
>
> Probably less convenient than having both.  There's likely to be
> external libraries which are still 32-bit.  Zlib for instance (I
> think, depending maybe on its config options).

I fail to understand how having `64' variants of most of the I/O
functions could be convenient.  What I was suggesting is to have only
one version of each function that uses, say, `scm_off_t' and
`scm_size_t' which both turn out to be 64-bit data types.

It's also unclear to me how this would cause troubles when interacting
(at the _source_ level) with 32-bit libraries.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: largefile64 on ports

[Kevin Ryde]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
> What I was suggesting is to have only
> one version of each function that uses, say, `scm_off_t' and
> `scm_size_t' which both turn out to be 64-bit data types.

(You only mean off_t here of course, there's no variation in size_t.)

Having off64_t unconditionally would, I believe, need
_LARGEFILE64_SOURCE in ports.h, but it's bad in general to force such
options in library headers like guile's.

A plain off_t is good for current source compatibility, and for the
convenience that if you're interfacing with a plain off_t library then
it's annoying to have to have explicit range checks down from off64_t.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel