Variable-length quantity: Difference between revisions

m (added whitespace before the TOC, added a ;Task (bold) header.)
Line 114:
16#200000# = :16#81#:16#80#:16#80#: 16#0#</pre>
 
=={{header|ANSI Standard BASIC}}==
<lang ANSI BASIC>
INPUT s$
LET s$ = LTRIM$(RTRIM$(s$))
LET v = 0
FOR i = 1 TO LEN(s$)
LET c$ = s$(i:i)
LET k = POS("0123456789abcdef", c$)
IF k > 0 THEN LET v = v*16 + k - 1
NEXT i
PRINT "S= ";s$, "V=";v
! Convert back to hex
LET hex$ ="0123456789abcdef"
LET hs$=" "
FOR i = LEN(hs$) TO 1 STEP -1
IF v = 0 THEN EXIT FOR
LET d = MOD(v, 16) + 1
LET hs$(i:i) = hex$(d:d)
LET v = INT(v/16)
NEXT i
PRINT hs$
END
</lang>
OUTPUT:
<pre>
S=200000 V= 2097152
200000
S=1fffff V= 2097151
1fffff
</pre>
=={{header|Bracmat}}==
Bracmat has no native octet array type. Luckily, the only octet that possibly can be zero in a VLQ is the last octet. Therefore a solitary VLQ can be expressed as a Bracmat string, which, just as a C string, is null terminated. If the last byte of the VLQ string has the high bit set, we know that the last octet contained 0-bits only. A problem is of course that VLQ's probably are meant to be concatenizable. With null bytes missing, this is no option for the VLQ's generated by this solution.