At 12:09 PM -0800 2/7/08, Hein, Nashua NH wrote: >On Feb 6, 11:56 pm, [EMAIL PROTECTED] (Hein van den Heuvel) >wrote: > >> The getpos _should_ return an opaque value (likely to be 2 int). >> It doesn't. >I a parallel thread I erroneously created Craig explains how the perl >getpos reverts to tell, unless it was build with /define=_LARGEFILE > >See: http://www.nntp.perl.org/group/perl.perl5.porters/2008/02/msg134073.html
Actually it reverts to tell in any case. It's just that with _LARGEFILE enabled, the tell-based implementation should be ok for large files, or at least for stream-oriented ones. > > What is worse, the same formula is >> used for indexed files where that 'byte offset' (rab$w_rfa4) is really >> a record ID which typically is less than 100 or so, but for certain >> usages can be several thousands, up to 65K. So the 'offset' can add >> into the vbn space. > >I can confirm this is a restriction/bug in the C-rtl. >Present in 8.3, and likely to remain there as permanent restirctions. You're talking about the tell/seek model, right? The fsetpos/fgetpos model avoids this problem? I almost said something in the post you cite above about how implementing fgetpos and fsetpos in terms of seek and tell has potential negative implications for record-oriented files on VMS over and above the large file problem. You may be able to get what you need by configuring and building a Perl that has the PerlIO layering mechanism disabled. Configure like so: $ @configure -"Uuseperlio" -"des" I *think* that will get you the real fgetpos and fsetpos from the CRTL, though doing a build is the only way to know for sure. What PerlIO does is documented in the following places; if you can live without it (and most things should still work), that may well be an answer. http://perldoc.perl.org/PerlIO.html http://perldoc.perl.org/perliol.html -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
