Skip Menu |

This queue is for tickets about the File-Map CPAN distribution.

Report information
The Basics
Id: 56646
Status: resolved
Priority: 0/
Queue: File-Map
People
Owner: LEONT [...] cpan.org
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:
Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Thu Apr 15 19:53:21 2010 user42 [...] zip.com.au - Ticket created
Subject: 64-bit off_t map position
Date: Fri, 16 Apr 2010 09:53:03 +1000
To: bug-File-Map [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
On debian i386 5.10 perl uses _FILE_OFFSET_BITS 64 so off_t is 64-bits and mmap() does in fact support offsets up to 2**44 or some such amount. It'd be good if File::Map passed such an offset through to the system call, so as to get at portions of files bigger than 4Gbytes. I see the typemap setup for off_t goes through an IV, which truncates to 32 bits. The easiest thing might be an NV and cast that to off_t, perhaps like, untested, (sizeof(off_t) > sizeof(IV) && NV_PRESERVES_UV ? (off_t) SvNV($arg) : SvIV($arg)) That'd get 53 bits out of the scalar, and worry about a proper sv -> I64 later. The perl-glib wrappers go via a string and atoll(), maybe the perl has something similar or better lurking.
  Thu Apr 15 21:11:43 2010 LEONT [...] cpan.org - Correspondence added
The size of IV's in perl depends on your compilation options. Debian and Ubuntu compile without `use64bitint` defined, so IV's are 32 bits on 32 bit architectures. I personally agree that that isn't making much sense as a default anymore. The next Debian release will probably have proper 64 bit integers for perl (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310995). I changed the typemap to an UV to win back one more bit (since negative offsets don't make sense anyway from a C perspective), but I'm not going to go the route of NVs. Madness lies there. Specially when you realize that many people are only harmed by such functionality (anyone with saner perls). I guess you'll just have to wait until Debian gets their perl in order.
  Thu Apr 15 21:11:44 2010 The RT System itself - Status changed from 'new' to 'open'
  Fri Apr 16 11:25:00 2010 LEONT [...] cpan.org - Severity Wishlist added
  Sat Apr 17 17:36:18 2010 user42 [...] zip.com.au - Correspondence added
Subject: Re: [rt.cpan.org #56646] 64-bit off_t map position
Date: Sun, 18 Apr 2010 07:35:47 +1000
To: bug-File-Map [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Leon Timmermans via RT" <bug-File-Map@rt.cpan.org> writes: Show quoted text
> > The next Debian release will probably have proper > 64 bit integers for perl (see > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310995).
I expect that'll bloat code and data and throw up various incompatibilities for no benefit :-). Show quoted text
> I changed the typemap to an UV to win back one more bit
The big problem in those conversions is they silently truncate, so if you write $offset=2**40 then it chops to 0. Often that truncation doesn't matter, but for an offset it's rather unfortunate as the system does support files of 2**40 and an mmap at such a position. You'd probably wish the ExtUtils/typemap file had an off_t entry already, since it's perl itself mucking about with _FILE_OFFSET_BITS.
  Sun Apr 18 17:48:40 2010 LEONT [...] cpan.org - Correspondence added
On Sat Apr 17 17:36:18 2010, user42@zip.com.au wrote: Show quoted text
> I expect that'll bloat code and data and throw up various > incompatibilities for no benefit :-).
No benefit other that filesizes and offsets working properly you mean ;-) Also upgrading to 5.12 introduces incompatibilities anyway, so it's not such a bad moment to switch,
  Tue Apr 20 07:35:28 2010 LEONT [...] cpan.org - Status changed from 'open' to 'rejected'
  Sun Jan 22 12:20:33 2012 LEONT [...] cpan.org - Taken
  Tue Jan 24 17:26:47 2012 LEONT [...] cpan.org - Correspondence added
On Thu Apr 15 19:53:21 2010, user42@zip.com.au wrote: Show quoted text
> On debian i386 5.10 perl uses _FILE_OFFSET_BITS 64 so off_t is 64-bits > and mmap() does in fact support offsets up to 2**44 or some such amount. > > It'd be good if File::Map passed such an offset through to the system > call, so as to get at portions of files bigger than 4Gbytes. > > I see the typemap setup for off_t goes through an IV, which truncates to > 32 bits. The easiest thing might be an NV and cast that to off_t, > perhaps like, untested, > > (sizeof(off_t) > sizeof(IV) && NV_PRESERVES_UV > ? (off_t) SvNV($arg) > : SvIV($arg)) > > That'd get 53 bits out of the scalar, and worry about a proper sv -> I64 > later. The perl-glib wrappers go via a string and atoll(), maybe the > perl has something similar or better lurking.
I've changed my mind. This feature is now released in 0.42. Leon
  Tue Jan 24 17:26:48 2012 The RT System itself - Status changed from 'rejected' to 'open'
  Tue Jan 24 17:26:48 2012 LEONT [...] cpan.org - Status changed from 'open' to 'resolved'