🚀 go-pugleaf

In article <f51n1tpamof.fsf@cogsci.ed.ac.uk>,
Robert Inder  <robert@cogsci.ed.ac.uk> wrote:
>
>The application uses sysread/syswrite and seek, and basically, it seems
>that these things do not work: I can seek once and sysread or syswrite, but
>thereafter &tell() aways returns 0, and seeks appear to have no effect.

&tell maps onto ftell() which tells you where you are in a stdio
stream. If you use sysread/syswrite (which map onto the Unix I/O
primitives), it's unreasonable to expect tell to give you a meaningful
answer. Even in circumstances where tell is defined, you cannot mix it
with sysread/syswrite - consider what happens when you run your
program on a system with multiple byte end-of-line markers.

To get the equivalent of tell, use something like: 
use POSIX;
$fileposition = sysseek HANDLE, 0, SEEK_CUR;

In C, it is possible, with care, to resynchronise the stdio stream
with Unix I/O; you can mix the two if you know what you're doing. Perl
doesn't export the necessary primitives to the application layer to
resynchronise an input stream so you should _never_ mix stdio with
sysread. For an uncomplicated life, EITHER use sysread, syswrite and
sysseek OR use read, write, print, and tell.

Peter

Robert Inder <robert@cogsci.ed.ac.uk> writes:

> Is Linux Perl really fundamentally broken?

No, your program is.  Look for the `sysread' entry in `man perlfunc',
where it says:

    It bypasses stdio, so mixing this with other kinds of reads,
    print(), write(), seek(), or tell() can cause confusion because
    stdio usually buffers data.

-- 
http://www.greenend.org.uk/rjk/