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

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

[Octave-bug-tracker] [bug #52116] Textscan filepointer bug is still pres


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #52116] Textscan filepointer bug is still present in Windows build
Date: Tue, 26 Sep 2017 18:09:06 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #9, bug #52116 (project octave):

I'm just adding a note here to diagnose the code.

I've printed out buf_size:

octave:4> A = textscan(fid,'%f %f %f %f %f %f %f %f %f %f %f %f
%f',4,"endofline","\r\n");
BUF_SIZE=320

By my estimate there are 836 non-EOL characters in the data file.  The file
size is 855 characters.  There look to be 10 lines in the file from an editor.
 That works out to two characters for EOL; seeing this is windows, no
surprise.  So starting from the end of line four in the data file, look 320
characters out and that puts us at


  1.81    101.73    234.13  -82.4  -59.6   -0.7   11.8  192.0  192.0  184.0 
196.0  100 2147483647
  2.01     99.88    232.86  -79.6  -60.3    3.6   -8.0  191.0  190.0  180.0 
195.0  100 2147483647
                    ^


That's not 99.88, the first read value of lastline=fgetl(fid), but it is
close.  I'm probably not accounting for something, but the point is that the
lost data has to do with the buffer size.

So, the obvious thought-o here is that specifying the number of lines to read,
"4", means that the size of data is limited to 4*80, or some other value other
than 80, without loss of generality.  That obviously isn't true.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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