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

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

[Octave-bug-tracker] [bug #52550] textscan drops delimiter character for


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #52550] textscan drops delimiter character for multi-character, cell-specified delimiter option
Date: Wed, 29 Nov 2017 14:49:01 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

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

I'll look at it this evening again, so wait just a bit.  The example I gave
of:


octave:35> b = " , ,1,2,3\n";
octave:36> textscan(b, '%d', 'delimiter', ',')
ans =
{
  [1,1] =

    0
    0
    1
    2
    3

}

octave:37> textscan(b, '%d', 'delimiter', {','})
ans =
{
  [1,1] = [](0x1)
}


is problematic.  It looks like it is the same type of bug still.  Inside of
the routine textscan::read_double in oct-stream.cc is the following code which
not only needs to put back a character if the value of i is zero, but notice
how it is exactly repeated code:


    is.clear ();
    if (! used_exp && ch != std::istream::traits_type::eof () && width_left)
      is.putback (ch);

    // Check for +/- inf and NaN
    if (! valid && width_left >= 3)
      {
        int i = lookahead (is, inf_nan, 3, false);   // false -> case
insensitive
        if (i == 0)
          {
            retval = numeric_limits<double>::Inf ();
            valid = true;
          }
        else if (i == 1)
          {
            retval = numeric_limits<double>::NaN ();
            valid = true;
          }
      }

    // Check for +/- inf and NaN
    if (! valid && width_left >= 3)
      {
        int i = lookahead (is, inf_nan, 3, false);   // false -> case
insensitive
        if (i == 0)
          {
            retval = numeric_limits<double>::Inf ();
            valid = true;
          }
        else if (i == 1)
          {
            retval = numeric_limits<double>::NaN ();
            valid = true;
          }
      }


It looks to me as though someone intended for the second instance to be
modified into checking for multi-character delimiters but never got around to
it.  Just a guess, so this will take some time to figure out what the
intention was and add a little loop for the second case similar to the
textscan::read_until routine.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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