From bynari@inbox.lv

Hello,

In perlopentut under section "File Locking" a filehandle is opened with
sysopen() and tell() is used on said filehandle. This contradicts the
information given in perldoc -f tell that sysseek() should be
used in conjunction with sysopen() and tell() with open().

-
Regards

Jeff T. Parsons
--- Your free mail Inbox.lv

This message contains no viruses.
Guaranteed by Kaspersky Anti-Virus.
http​://www.antivirus.lv

From nick@ing-simmons.net

Bynari @​ Inbox . Lv <perl5-porters@​perl.org> writes​:

# New Ticket Created by bynari@​inbox.lv
# Please include the string​: [perl #30788]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org​:80/rt3/Ticket/Display.html?id=30788 >

Hello,

In perlopentut under section "File Locking" a filehandle is opened with
sysopen() and tell() is used on said filehandle. This contradicts the
information given in perldoc -f tell that sysseek() should be
used in conjunction with sysopen() and tell() with open().

File handles opened by sysopen() and open() are essentially identical
once open. sysopen just gives more detailed control of how numeric
fd is opened (on POSIX-ish systems anyway).

It isn't mixing tell/sysopen or sysseek/open that is the problem.
The issue is one of _use_ of buffering (or lack of it).
tell() belongs to the buffered world of <$fh>/seek/print
sysseek() belongs to the world of sysread/syswrite.
So using tell() on something that is used in unbuffered fashion is
a potential problem. However tell() is likely to "flush" buffers
so that if <>/print have been used the stream is put back into
a state where sysread/syswrite work again.
As far as I can tell the code in perlopentut is good.

So all-in-all I think it is the 'perldoc -f tell' section
that needs work​:

"
  Do not use tell() on a filehandle that has been
  opened using sysopen(), use sysseek() for that as
  described above. Why? Because sysopen() creates
  unbuffered, "raw", filehandles, while open() cre­
  ates buffered filehandles. sysseek() make sense
  only on the first kind, tell() only makes sense on
  the second kind.
"

That paragraph is almost completely wrong...

Something like​:

"
Do not use tell() (or other buffered IO operations) on a file handle
that has been manipulated by sysread(), syswrite() or sysseek().
Those functions ignore the buffering while tell() does not.
"

Would be better.

I think one can switch back and forth like so

  # Switch from sysread world to buffered world​:
  seek($fh,sysseek($fh,0,1),0);
  # <$fh> okay now

  # Switch from buffered to sysread world​:
  seek($fh,0,1);
  # sysread() okay now

-
Regards

Jeff T. Parsons
--- Your free mail Inbox.lv

---
This message contains no viruses.
Guaranteed by Kaspersky Anti-Virus.
http​://www.antivirus.lv

The RT System itself - Status changed from 'new' to 'open'

From @rgs

Nick Ing-Simmons wrote​:

So all-in-all I think it is the 'perldoc -f tell' section
that needs work​:
...
That paragraph is almost completely wrong...

Something like​:
...
Would be better.

Thanks, applied as #23184.

@rgs - Status changed from 'open' to 'resolved'