Front page | perl.perl5.porters |
Postings from March 2012
David Golden: > On Sat, Mar 3, 2012 at 11:02 AM, Aristotle Pagaltzis <pagaltzis@gmx.de> wro= > te: > > > > Based on this particular usage pattern I suggested this option: to hold > > back an incomplete trailing UTF-8 sequence after a fixed length read, > > and prepend them to the next read from that file handle. I don=E2=80=99t = > after > > all care about the exact amount of data, I just want it in large chunks. > > > > That was shot down. > > That's too bad. ... > situation. Delivering fewer bytes seems allowed by the documentation. It has to be allowed, because the file might be short, and there might not be as many bytes as $/ demands. But doing a short read in the middle of the a file would surprise me since as far as I know it is otherwise unprecedented. The anology I would make is with the Unix 'read' call. read(fd, buf, size) is documented to read at most 'size' bytes, and on pipes and sockets it often does read fewer than you asked for, if fewer are available. But on files, it is guaranteed to do this only at the end of the file, when you asked for more bytes than there are left between the file pointer and the end of the file. If youi ask for n bytes and there are n to give you, that is how many you get, guaranteed. At present, $/ delivers a short read in exactly the same circumstances as the 'read' function. Suppose it were a fatal error to read from a multibyte-encoded string while $/ was set to a number. What would be wrong with that?Thread Previous | Thread Next