Forkいいじまです。
> > > .\"O ----------------------------------------
> > > .\"O .TP
> > > .\"O \fB\-a\fR, \fB\-\-alignment\fR=\fI\,NUMBER\/\fR
> > > .\"O align strings to NUMBER bytes (default: 1)
> > > .TP
> > > \fB\-a\fP, \fB\-\-alignment\fP=\fI\,NUMBER\/\fP
> > > 文字に対して NUMBER バイトを割り当てます (デフォルト: 1)。
> >
> > 文字→文字列 かな？
> >
> > そもそもこのオプションを理解していないので、
> > 適切なコメントができていないかもしれません。
>
> 原文が strings なので「文字列」とします。
> 処理内容はソースを見ても、よくわかりませんでした。
> 文字列を出力する際のバッファサイズ(あるいは出力幅)
> を定めているのか、と推測します。
>
> 再訳
> 文字列に対して NUMBER バイトを割り当てます
> (デフォルト: 1)。
バイト列に対してalignmentという場合、「各要素のサイズが既定のバイト数の倍数になるように調整する」という意味が強いです。ついでにいうと align X to Y bytes は「XをYバイトの位置に揃える」です。「XにYバイトを割り当てる」なら「allocate Y bytes to X」になるはずです。
☆ ☆ ☆
（以下、ご存知の方も少なくないと思いますがご容赦ください。）
たとえば、C言語でこんな構造体を作ったとします：
struct EXAMPLE
{
char c;
short i;
double f;
};
この場合、x86の流れをくむCPUならたとえば
c：構造体の先頭から0バイト目
s：構造体の先頭から1-2バイト目
f：構造体の先頭から3-8バイト目
全体のサイズ：11バイト
という内部構造になっていても全く問題ありません。これが 1-byte alignment です。
ところが、最初から32bit以上で設計されたCPUの中には「16bitのデータは偶数の番地から、32bitのデータは4の倍数の番地から始まっていないといけない」という制約を持つものが多々あります。もちろん「64bitのデータは8の倍数の番地から」という制約もありえます。その場合、この構造体の内部構造は、たとえば次のようになっていなければいけません：
//4-byte alignmentの場合
c：先頭から0バイト目
//1バイトの空き
i：先頭から2-3バイト目
f：先頭から4-11バイト目
全体のサイズ：12バイト
//8-byte alignmentの場合
c：先頭から0バイト目
//1バイトの空き
i：先頭から2-3バイト目
//4バイトの空き
f：先頭から8-15バイト目
全体のサイズ：16バイト
あるいはx86系でもSSE命令などを使う場合、画像1ピクセルの色情報が24bit(8x3)や48bit(16x3)だったとしても、CPUレジスタのビット数は2のべき乗ですから、メモリ上では
struct RGB32 { unsigned char r,g,b,dummy;};
struct RGB64 { unsigned short r,g,b,dummy;}:
のように32bitや64bitのデータとして扱ったほうが効率がよくなります。
☆ ☆ ☆
元に戻って元の文章のalignmentの意味を考えると、デフォルトの 1-byte alignment ではたぶん、一つの文字列が終わったらヌルバイトを1個だけ置いてすぐ次の文字列が出力されるのだと予想します。
そしてたとえば 16-byte alignment を指定したとして、90バイトのテキストを出力する際には、90バイトの本文の後にヌルバイトを6個配置して全体で96バイトになるようにする、ということではないでしょうか。
これは結局のところ、実際に試して白黒つけるしかないと思います。
--
飯嶋 浩光／でるもんた・いいじま ＠ PC
IIJIMA Hiromitsu, aka Delmonta
Email <delmo****@denno*****>