question on funny behaviour of binary scan

question on funny behaviour of binary scan

Post by 0464292012 » Sat, 12 Feb 2005 22:52:06


Hi Tclers,
,
i've run into trouble using binary scan:

% binary scan "\x55" BBBBBBBB a b c d e f g h i
1
% set a
0
% set b
can't read "b": no such variable

% binary scan "\x55\x55" BBBBBBBB a b c d e f g h i
2
% set a
0
% set b
0
% set c
can't read "c": no such variable

Now a is OK, b should have been 1 this look like scan
took the next byte

% binary scan "\x55\xaa" B4B* a b
2
% set a
0101
% set b
10101010

a is OK but b should be 12 Bits ie: 010110101010
and not 8 Bits?

tested versions: tcl-8.4.2, tcl-8.4.6
there seems to be no bug listed for
the binary command at sourceforge.

uwe
 
 
 

question on funny behaviour of binary scan

Post by Bruce Hart » Sun, 13 Feb 2005 00:15:19


it's not a bug, it's a feature!
seriously, that is how it is docum,ented to work - check out

http://www.yqcomputer.com/ #M27

which has: (emphasis mine)

b
The data is turned into a string of count binary digits in low-to-high order
represented as a sequence of ``1'' and ``0'' characters. The data bytes are
scanned in first to last order with the bits being taken in low-to-high order
within each byte.
**********************************************************
***** Any extra bits in the last byte are ignored. ******
**********************************************************
If count is *, then all of the remaining bits in string will be scanned.
If count is omitted, then one bit will be scanned. For example,

binary scan \x07\x87\x05 b5b* var1 var2

will return 2 with 11100 stored in var1 and 1110000110100000 stored in var2.

B
This form is the same as b, except the bits are taken in high-to-low order
within each byte. For example,

binary scan \x70\x87\x05 B5B* var1 var2

will return 2 with 01110 stored in var1 and 1000011100000101 stored in var2.


Bruce

 
 
 

question on funny behaviour of binary scan

Post by 0464292012 » Sun, 13 Feb 2005 02:15:08

Hi Bruce,
thanks for your answer.
I was rather fixated on scanning 8Bits of a Byte into 8 vars.
Allways loosing the remaining Bits in a Byte doesn't seem right.
The way it is makes binary scan format "B" and "b"
rather less usefull .-(

<man example>
binary scan \x70\x87\x05 B5B* var1 var2
will return 2 with
01110
stored in var1 and
1000011100000101

3Byte String is 24Bit.
var1 is 5Bit
var2 is 16Bit

This would mean that after every format specifier
the "cursor" is aligned on the next _byte_ boundary.

I would prefer the _cursor_ to be stepped in conformance
with the alignment of the next format specifier.

i.e. binary scan <2bytes> BBB2H3 Bit1 Bit2 BitPair Val_12_BitWide
should work.
While whishing for the unwishable:
The ability to force scanned values to unsigned would be nice as well.

uwe
 
 
 

question on funny behaviour of binary scan

Post by Andreas Le » Sun, 13 Feb 2005 02:47:38


yes, unfortunately, it *does* mean it.

yes, that would have been more useful, but is now
rather too late to change, at least without any trick
to ensure that "BB",... behaves as before - for compatibility.

Wait, "alignment of the next format specifier" isn't it!
it should never skip whole bytes, not even if next comes
e.g. an odd(in string)-aligned 4byte-integer.
(this should only affect b and h (and uppercase))

Thus, not BB (nor bB,Bb,bb, b42B6, etc...) would possibly
change their meaning, but some new trick would have to
be found to request this new feature.


With some suitably changed format-string: yes

Amen. yes,yes,yes!
Though even there is some caveat: this only works for integral
types with a *smaller* range than the internal type (int or wide),
otherwise this distinction is lost immediately.
 
 
 

question on funny behaviour of binary scan

Post by 0464292012 » Sun, 13 Feb 2005 03:26:47


well it doesnt skip whole bytes but 88% of perfectly good
set of 8Bits ;-)
yes mixing B/b and H/h is abomination
>
> Amen. yes,yes,yes!
> Though even there is some caveat: this only works for integral
> types with a *smaller* range than the internal type (int or wide),
> otherwise this distinction is lost immediately.

yes, sure, but in all the cases where i stumbled over this
it was with Bytes and Shorts.
binary scan is nice and fast and you loose it all when you have
to fix all your values with
foreach val $list {
append newlist [ expr ...
}
set list $newlist
>


re unsigned:
I had a look at the Binary src and startet to fix it for me.

re formatspec:
i thought about adding specifiers for signed unsigned and skip,noskip
+ read signed
- read unsigned ( c,Ss ?Ii? )
, don't skip
: align on size of following spec?
:n align on n byte boundary ( from start )

B,B,B2,B4 would fill 4 vars consuming 1 Byte
B:B:B2:B4: would fill 4 vars consuming 4 Bytes
S-4,S+4,c,:4,I* would read 4 unsigned short, 4 signed short
1 byte , align on a 4 Byte Boundary

which would make the formatstrings better readable as well.
I allways do have trouble counting the H's and S's and I's .

uwe