octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #57596] Should the "len" argument of "fgetl" a


From: Andrew Janke
Subject: [Octave-bug-tracker] [bug #57596] Should the "len" argument of "fgetl" and "fgets" mean bytes or characters?
Date: Wed, 10 Jun 2020 13:42:45 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:73.0) Gecko/20100101 Firefox/73.0

Follow-up Comment #10, bug #57596 (project octave):

> If you are arguing that for UTF-16, "one character" should be one two-byte
"UTF-16 code unit" instead of one Unicode code point, why don't you also argue
that, for UTF-8, "one character" should be one one-byte "UTF-8 code unit"?

I am arguing that. (We're talking about the question of how to handle UTF-16
surrogate pairs here, right?) Largely because this is how I've seen it done in
other languages, it tends to work all right, it removes the need to strongly
distinguish between UTF-16 and UCS-2 input modes (which is an advanced topic
even for programmers with a decent grasp of Unicode), and it would provide for
Matlab compatibility (because Matlab does UCS-2, but most Matlab programmers
I've talked to pretend it's UTF-16, and in that sense it passes through
surrogate pair code units unmolested, but treats them as one character each).
But this point is the part I'm least confident of among the points I made, and
I could probably be convinced otherwise.

> If you are hinting on whether the "char" type in Octave should have a size
of one or two bytes: That is another issue and should be kept separate from
this bug. 

I am not hinting. I recognize that's a whole nother discussion, and not trying
to drag it in here.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57596>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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