[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #55452] fopen() does not support encoding argu

From: Andrew Janke
Subject: [Octave-bug-tracker] [bug #55452] fopen() does not support encoding argument
Date: Wed, 13 Mar 2019 03:06:18 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36

Follow-up Comment #28, bug #55452 (project octave):

Here's what I'm concerned about: if "fgetl" and "fgets" do encoded input, but
their "len" arguments are expressed in bytes instead of characters:

Is "len" the number of input bytes (from the file) or output bytes (in the
returned string)?

If "len" is the number of input bytes, and you specify a length that leaves
off reading in the middle of a multi-byte sequence, what happens? If you just
leave it as is, the file pointer is no longer a correct position for starting
decoding again. And the bytes that were read are not a complete valid string
in their input encoding.

Consider the example of a file containing "Hello!\nGoodbye!\n" encoded in
UTF-16 little-endian. ("samples/hello - UTF-16 LE.txt" in my test repo.) What
should happen if you open it and do "str1 = fgetl(fid, 3); str2 = fgetl(fid,


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]