#3314 Inline scan returns too many items

obsolete: 8.4.11
23. [scan] (15)

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 {} {}


  • Schelte Bron

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

    Schelte Bron - 2005-11-27

    Patch to tclScan.c

  • Jeffrey Hobbs

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

    Jeffrey Hobbs - 2005-11-29

    Logged In: YES

    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

    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.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks