[Octave-bug-tracker] [bug #45752] strread causes "concatenation of different character string types" warning

[Philip Nienhuis]

Update of bug #45752 (project octave):

                  Status:                    None => Invalid                
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

Running:

>> warning ('error'); strread ('1,1', '%d', 'delimiter', ',')
error: concatenation of different character string types may have unintended
consequences
error: called from
    strread at line 393 column 21
error: evaluating argument list element number 1
error: called from
    strread at line 393 column 21
>> edit strread
error: missing semicolon near line 163, column 9 in file
'/home/philip/devel/octdev/oct410+/../devINT/scripts/miscellaneous/edit.m'
error: variable switch label near line -1, column -1 in file
'/home/philip/devel/octdev/oct410+/../devINT/scripts/miscellaneous/edit.m'
error: variable switch label near line -1, column -1 in file
'/home/philip/devel/octdev/oct410+/../devINT/scripts/miscellaneous/edit.m'
>> which strread
error: concatenation of different character string types may have unintended
consequences
error: called from
    which at line 36 column 24
error: evaluating argument list element number 2
error: called from
    which at line 36 column 24
>>


so the code 'warning ("error")' screws up somewhere.

The code in strread.m itself (L.393) is here:

delimiter_str = unique ([white_spaces delimiter_str]);

and further debugging using your strread command line:

:
debug> uint8 (white_spaces)
ans =

  32   8  13  10   9

debug> uint8 (delimiter_str)
ans = 44
debug> class (white_spaces)
ans = char
debug> class (delimiter_str)
ans = char


... I see no coding errors or runtime errors that could validly provoke the
warning or even error messages. 
Looking at the next series of messages above, it is much more probable that
the simple code 'warning ("error")' has some unintended and unexpected
consequences - see your other report for bug #45753.

As to your strread.m speed complaint:
We all wait for a binary textscan() as replacement for strread.m. Some years
ago JWE supplied a skeleton, but that is all that has come up. If you want to
speed up strread.m while keeping all its user options (required as backend for
current textscan.m), well, good luck with it.

I'm closing this report with "invalid" and refer to bug #45753.

    _______________________________________________________

Reply to this item at:

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

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