しらいです。

In article <050102183025.M0121129@athena.ginganet.org>,
Kawaguti Ginga <ginga-fj-swentemporal@ginganet.org> wrote:
>川口です

>> CPU の 64ビットと OS の 64 ビットは別の話ですから。llseek() 
>> とか付けなければ、アドレスだけ 64 ビットでも64ビット対応の 
>> OS とは言わないかも。逆に llseek() があれば、アドレスは 32 
>> ビットのままでも 64 ビット OS とは言えるんじゃないかな。
>
>既にツッコミが入ってますが
>なんか通常の 「64bit OS の定義」とは <ムチャクチャ> 違いますよね，それ．

　「違う」と言うよりむしろ「逆」でしょう。64bit OS で何故そ
んな LFS 用の system call が必要になるのか、全く意味不明です。
「英和辞典を持ち歩いている人が native English」みたいな。
　所属は情工の先生のように見えるんですけど、これまでの数々の
記事を読む限りでは、computer science に関する知識は乏しい方
のようですので、余り真剣に相手にしない方が賢明かと。

　因みに、世間で 64bit OS と呼ばれている Tru64 UNIX や HP-UX
(IA64) には llseek() も lseek64() もありません。HP-UX の方に
は lseek64() はありますが、man page にも「32bit アプリ用」と
書かれています。
　int 幅が 64bit ある OS で敢えて off_t や size_t だけ 32bit
にする理由などどこにもないので、これらの OS では当然最初から
lseek() の第二引数は 64bit あります。
　尤も、64bit CPU を使いながらも組込み用途などで 64bit 幅の
address 空間が不要な場合は、敢えて 32bit 幅の lseek() を用意
するケースがあり得るでしょうけどね。

　一方、lseek64() 等の LFS 対応が成されていれば 64bit OS で
あるという命題についてですが、昨今の UNIX では LFS が当たり
前に浸透していますので、LFS 非対応 OS は滅多にありません。
　LFS 非対応時の Linux kernel ですら、_llseek() という関数を
使って 32bit 引数二つを組み合わせて 64bit offset address を
指定出来ていました。
　LFS やそれに準ずる枠組で実現される 64bit file access をも
って 64bit OS と称するならば、現役 UNIX は殆んど全部が 64bit
OS と呼べることになると思います。


　なお、LFS については下記 URL を参照して下さい。
        http://ftp.sas.com/standards/large.file/

＃　規格上も LFS は「32bit UNIX 用」って書いてあるじゃん。

-- 
                                               しらい たかし