#3314 Inline scan returns too many items

obsolete: 8.4.11
open-invalid
Jeffrey Hobbs
23. [scan] (15)
5
2005-12-02
2005-11-27
Schelte Bron
No

Doing: [scan 0.99 %d.%d.%d.%d a b c d] returns 2 and
only variables a and b are set. Variable c and d are
not being touched. If these variables did not exist
before, they still don't exist after the operation.
Otherwise they will still have their old value.

According to the manual page: "If no varName variables
are specified, then scan works in an inline manner,
returning the data that would otherwise be stored in
the variables as a list".

From this information I expect [scan 0.99 %d.%d.%d.%d]
to return a list with two elements. However, the
command returns a list with four elements: 0 99 {} {}

Discussion

  • Schelte Bron
    Schelte Bron
    2005-11-27

    • milestone: --> obsolete: 8.4.11
     
  • Schelte Bron
    Schelte Bron
    2005-11-27

    Patch to tclScan.c

     
    Attachments
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2005-11-29

    • status: open --> pending-invalid
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2005-11-29

    Logged In: YES
    user_id=72656

    Note that the next sentence is "In the inline case, an empty
    string is returned when the end of the input string is
    reached before any conversions have been performed.", and
    perhaps that needs augmenting to say that each %-sub that
    goes unmatched also makes an empty string. Inline scan does
    intentionally operate to return a list equal in length to
    the number of %-subs.

     
  • Schelte Bron
    Schelte Bron
    2005-12-02

    • status: pending-invalid --> open-invalid
     
  • Schelte Bron
    Schelte Bron
    2005-12-02

    Logged In: YES
    user_id=37987

    That next line refers to the fact that [scan "" %d.%d.%d.%d]
    returns an empty string and not a list of four empty
    strings. That is actually consistent with the expected
    result I described.

    The only situation that is inconsistent is a partial match.
    I have seen the code and noticed that it intentionally adds
    empty list entries. But that doesn't automatically make it
    the right thing to do.

    I do realize that this is unlikely to be changed because
    that might break existing code that accounts for the current
    behavior. So probably the only thing that can be done now is
    to warn people about this illogical behavior in the manual page.