[Octave-bug-tracker] [bug #38003] textscan() "endofline" compatibility

[Philip Nienhuis]

Follow-up Comment #1, bug #38003 (project octave):

First of all, is this really a bug?

(1) At the time I added endofline processing to textscan/textread, the ML docs
only mentioned "\n", "\r\n" and "\r" EOLs, plus that a default value for
endofline param is to be determined from the file at hand.
==> there's at least a bit of undocumented ML behavior.

(2) In real life I've never seen "\n\r" EOLs.
I did encounter "\n\r" sequences but those usually were meant as special
encodings, not EOL sequences.

(3) I wonder if your example is really valid as endofline stuff is only...,
well, "supported"? .. when reading real files, not character strings.

FYI: strread.m (textscan's work horse) does:

octave:4> a = strread (sprintf ('A\r\nB\n\rC\rD\nE'), '%s')
a =
{
  [1,1] = A
  [2,1] = B
  [3,1] = C
  [4,1] = D
  [5,1] = E
}
octave:5>


Note that it may well be that strread.m does it OK just "by accident" :-)


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?38003>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/