#629 Use @ to report offset in [binary scan]


Currently, using @ without an index in [binary scan] is an error.
The [binary scan] implementation can be easily modified to allow an @ without an index to report the 'current' offset, storing it in a variable, like with other format specifiers.
This makes it easier to track the offset; it must currently be done manually.
Attached is a patch for the code and a patch for some tests, for Tcl 8.5.12.
If this is 'approved' then I'll write more tests, adjust the documentation and submit new patches.


  • Donal K. Fellows

    • labels: 322376 --> 12. ByteArray Object
    • priority: 4 --> 7
  • Donal K. Fellows

    Seems like a reasonable idea. Not looked at the changes yet.

  • Stuart Cassoff

    Stuart Cassoff - 2012-08-05

    Development continues in the stwo-dev86 branch on core.tcl.tk.

  • Andreas Leitgeb

    Andreas Leitgeb - 2012-08-26

    I've just submitted a new TIP, where (among other things) I prefer a new character "p" to a no-count-@.
    Once the TIP shows up, please read and judge my reasoning (in section "rejected alternatives").

  • Stuart Cassoff

    Stuart Cassoff - 2012-12-08

    The reasoning in tip 410 for not wanting to use "@" is:

    'I consider a typo "@ 42 ..." to be common enough to not
    want to give it a new unexpected meaning and side-effect.'

    What sort of typo is "@ 42" and how would that be
    different from "p 42"?

    I like having "@" mean the same thing in [binary scan]
    and [binary format]; it's less work for my brain.

    I'd like to move forward with this.
    It's easy to do, makes sense and is useful.
    It's much more lightweight than anything tip'ed.
    And there is an implementation. :)

  • Andreas Leitgeb

    Andreas Leitgeb - 2012-12-08

    The difference between "@ 42" and "p 42": "@..." with a count requires only a value argument (namely the count), not a variable name. If a blank crept into it, it would merrily treat some value argument as a variable and write a value into it, before it stumbles over the numeric literal and throws an error. At the time of error thrown, some random variable is already overwritten. With "p 42", also an error would be thrown, but p would at least be given a variable name, to which a sane value is written, before the error get thrown on hitting blank 42.

    That's my reason. If it is entirely unconvincing for you, then so be it. I'd consider the feature added your way with only @ to be still an improvement over current state, but I do think that using a new "p" is still better.