[EMAIL PROTECTED] (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 unc
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (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
>
[EMAIL PROTECTED] (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 in
Hi,
Kevin Ryde <[EMAIL PROTECTED]> 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
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 descrip
Greg Troxel <[EMAIL PROTECTED]> 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
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 sys
Greg Troxel <[EMAIL PROTECTED]> 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 d
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
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
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 fie
11 matches
Mail list logo
