##なにやら面白そう
#binary.packについて教えて下さい。
#固定長の要素を基本にしたバイナリファイルを扱っていて、いま8バイト分の領域に
データ型を識別するための文字列'int32','int64','char','double'が入っていて、
余った部分には'\0'が埋まっています。その型の識別子の直後にネットワークバイト
オーダーでデータの次元数が入っていて、続いてその次元の次数と対応するデータが
だだだだだ・・・と並んでいるようなものが入力です。
#このとき頭の「型識別子」と「次元数」だけ取るのに unpack "Z8@8N" としても
NULL終端の一文字を拾った次の'\0'からNを拾って来ているように見えるのです。
#そもそも仕様を勘違いしている可能性がないとも言い切れないですが・・・もしかしてこれがリファレンスマニュアルにあるバグでしょうか。
#binary.packはAlexが書いてくれたやつで私は中身をあんまり把握してないんですが
#@の処理にlong known bugがあったような気がする
#Date: Wed, 10 Nov 2004 11:34:42 -1000 (HST)
X-Mailer: Mew version 3.3 on XEmacs 21.4.15 (Security Through Obscurity)
Hi, Alex.
Recently I bumped into a weird behavior of '@' in unpack:
gosh> (use binary.pack)
(#<module binary.pack> #<module gauche.interactive>)
gosh> (unpack "@1ccc" :from-string #*"\x00\x01\x02\x03")
(1 2 3)
gosh> (unpack "@1ccc" :from-string #*"\x00\x01\x02\x03")
(0 1 2)
gosh> (unpack "@1ccc" :from-string #*"\x00\x01\x02\x03")
(0 1 2)
Though I haven't digged it thoroughly, I suspect it is
because of the caching and use of parameters for value-len-param.
Probably the cleaner approach is to make packer and unpacker
state monads, so we can pass vlp via arguments and return values
(though it's a bit awkward in Scheme than Haskell, since we need
to deal with passing states explicitly).
#これがまだ直ってない
Gauche > Archives > 2009/07/15