packされたbytes型データの質問

Question

こんにちは。

以下のpythonのstructモジュールに関しての記事にて分からないところがありました。
下記コードは下記リンク先に載っていたものです。
リンク内容

data = pack('hhl', 1, 2, 3)
data
#b'\x01\x00\x02\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00'

コードのようにやると、コメントのようにpackされるとのことなのですが、h,lはそれぞれ2,4バイトで処理すると書いていて、全部で8バイトにならないのか？と思いました。
スラッシュとスラッシュとの間が1バイトだと考えているので、全部で16バイトになっています。
私の解釈のどこが間違っているのでしょうか？

よろしくお願い致します。

Comments

[can110]

コメントのような結果が再現できません。実際に実行した結果を追記ください。

[slimat]

すみません、記述ミスがありました。コードは全てサイト(リンク)に載っていたものです。

Answer 1

リファレンスより：

7.1.2.1. バイトオーダ、サイズ、アラインメント(原文)

デフォルトでは、C での型はマシンのネイティブ (native) の形式およびバイトオーダ (byte order) で表され、適切にアラインメント (alignment) するために、必要に応じて数バイトのパディングを行ってスキップします (これは C コンパイラが用いるルールに従います)。

ということで、環境により、デフォルトでは8バイト境界にアラインメントされるようです。=でアラインメントを抑止できます。

pack('=hhl', 1, 2, 3)
#=> b'\x01\x00\x02\x00\x03\x00\x00\x00'

Windowsだと、デフォルトでもアラインメントされませんでした。

Comments

[slimat]

回答ありがとうございます。
=をつけた結果がそのようでしたら、納得できます！

只、もしも1、2、3、のような小さな値ではなく、1を256？に変えた場合には
b'/xff/x01/x00/x02/x00/x03/...
のようになるのでしょうか？

[otn]

511, 2, 3 を指定したらそうなりますね。

[slimat]

511?!
xffは255だと思っていたのですが、合っているのでしょうか？

[hayataka2049]

hはshortで2byte整数なので、01ffで511です。リトルエンディアンなので。ただ、\x01のあとの\x00が余計ですが。あと、/xじゃなくて\xですが（バックスラッシュ）。
>>> struct.pack('=hhl', 511, 2, 3)
b'\xff\x01\x02\x00\x03\x00\x00\x00'

[slimat]

回答ありがとうございます。
xffの後にx01/x00となることを忘れていました。
macキーボードなんですけど、キーが見当たらないなと思っていたところ、調べることで解決しました。

Answer 2

アラインメント・パディング絡みじゃないですかね。私の環境はlinux 64bitです。

>>> import struct
>>> struct.pack("hhl", 1,2,3)
b'\x01\x00\x02\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00'
>>> struct.pack("@hhl", 1,2,3)
b'\x01\x00\x02\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00'
>>> struct.pack("=hhl", 1,2,3)
b'\x01\x00\x02\x00\x03\x00\x00\x00'
>>> struct.pack("<hhl", 1,2,3)
b'\x01\x00\x02\x00\x03\x00\x00\x00'
>>> struct.pack(">hhl", 1,2,3)
b'\x00\x01\x00\x02\x00\x00\x00\x03'

デフォルトでは、C での型はマシンのネイティブ (native) の形式およびバイトオーダ (byte order) で表され、適切にアラインメント (alignment) するために、必要に応じて数バイトのパディングを行ってスキップします (これは C コンパイラが用いるルールに従います)。

7.1. struct — バイト列をパックされたバイナリデータとして解釈する — Python 3.6.5 ドキュメント

Comments

[slimat]

回答ありがとうございます。

そのようなことが原因だったのですね！理解できました。

Answer 3

実行環境のshortやint型のサイズによります。
一般的なサイズは7.1.2.2. 書式指定文字に記載されていますが
提示サイトの実行環境ではshortが4byte、longが8byteなのだと思われます。

ちなみに当方環境Win10のPython 3.5.6 |Anaconda custom (64-bit)| (default, Aug 26 2018, 16:05:27) [MSC v.1900 64 bit (AMD64)] on win32ではb'\x01\x00\x02\x00\x03\x00\x00\x00'となりました。

7.1.2.3. 使用例でもpack('hhl', 1, 2, 3)の結果はb'\x00\x01\x00\x02\x00\x00\x00\x03'と記載されています。
ここで\0x01などの順番が異なるのは、マシンのエンディアンの違いによるものなので無視してよいです。

Comments

[can110]

サイズというよりアライメントするかどうかの違いのようですね。微妙にずれた回答でした…

[slimat]

回答ありがとうございます。

リトルエンディアンだと、
b'/x00/x01/と書かれているように、前の方にパディングするのですね！

Answer 4

macOS(10.14.1, Mojave)では以下のような結果でした。

from struct import pack

pack('@hhl', 1, 2, 3)  
# b'\x01\x00\x02\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00'
pack('hhl', 1, 2, 3)
# b'\x01\x00\x02\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00'
pack('<hhl', 1, 2, 3)
# b'\x01\x00\x02\x00\x03\x00\x00\x00'

Comments

[slimat]

回答ありがとうございます。

また今度、<をつけることの意味を調べてみたいと思います。