９月頭のことになりますが、ドメイン更新しました。
今までは２年単位での契約だったんですが、面倒なので契約単位を伸ばしました。安くなるし。
ま・・・安いかどうかはその時のレート次第ですが割引率が大きいのでそこまで円高にはならんだろうという判断です。
当然本心は更新が面倒くさいからですけどね。
英語読むの疲れるから。

最近また仮面ライダーを観てます。
今年のは555（←ﾌｧｲｽﾞと読みます）ですが、なんかまぁ青臭い奴らが好きだ嫌いだ三角関係だなんだと、そんな話ばっかりでうんざりだったんですよ。
そういう傾向の作品みたいに同志のはずなのに間に伝言が入っただけで誤解の連続ですれ違い。もう見てらんない（´Д⊂

しかーし、今週はマジでﾋﾞｸｰﾘした。
先週ﾌｧｲｽﾞｷﾞｱ（変身ﾍﾞﾙﾄ）を捨ててしまったタっくん（主人公）。
あ〜あまたセンチな話かよ〜戦えよ〜と思っていたら今週のラストで何とオルフェノク（ｼｮｯｶｰの怪人と思いねぇ！）に変身しちゃった！

目玉が飛び出るほど驚いた。゜゜（Д　）


こないだ買ったﾁｭｰﾅ＆ｷｬﾌﾟﾁｬﾎﾞｰﾄﾞ使ってiEPG予約して録ってるので早起きしなくなりました（´・ω・｀）

まぁ難しい話はおいといて



・・・・・・・・・


・・・ｷﾀ・・


ｷﾀ━━(ﾟ∀ﾟ)━( ﾟ∀)━( 　ﾟ)━(　　)━(　　)━(ﾟ 　)━(∀ﾟ )━(ﾟ∀ﾟ)━━!!!

京セラの AH-K3001V が JATE 通過！

と思ったとたんに WPC EXPO 2003 に展示！

ｷﾀ━━━ﾟ(∀)ﾟ━━━!!


痛恨の戻り機種変のため縛りリセットされてるのが痛いが、JATE通過から最速３ヶ月として12月？
元々４月に日本無線機に機種変した時点でダメなのでいいや。
たぶん、卸値＋でも余裕で買いますね。

新たな可能性、AirH"phone しかし初代はあまりの通話品質（というか回線交換時の接続性）の悪さに投げ出してしまったものの、そのコンセプトは未だ魅力満載！
加えて通話には定評のある京セラさんですよ！
正直カメラは要らないんだけど・・・それでも仮に日本無線と同じアプリプロセッサを搭載してるのなら30万画素クラスの搭載も夢ではない。
ベースバンドの呪縛は無いと言えば無いのですよ。

全てが日本無線のアッパーであることを期待できるわけではないのは当然です。
が、この段階、詳細未定、発売日価格全て未定でモックと型番のみが公開されている段階、ユーザは今が一番楽しい時期と思われ。

はゃくぅ〜詳細が発表されないかなぁ〜(*^∀^)

先日の続きです。
そんなこんなで真面目に勉強しようとすると、まぁあれだ、本を買うわけですね。
この出費の痛みが、いわば「俺は勉強の為に前向きに代償を支払ったのだ」という自己満足に変わり、要するに問題集を早い時期に買ったやつほど勉強しないの法則のメカニズムですだ（´･ω･｀）

ところで、実はK&R2を買いに行ったのです。
カーニハン＆リッチー共著、the C Programming Language, Second Editionだす。当然英語なんて読めないので訳本の「プログラミング言語Ｃ第二版」ダス。
まぁあれだ、判断の根拠としては手元に置いておきたい本なわけですよ。面白いかどうかはともかくとして。
で、実際に書店で手にとって見ると、うゎ面白くねぇ・・・リッチー様ごめんなさい。俺には最後まで読破できない自信があります。

というわけで早々にやめ、（まぁいずれ手元に置でしょうけど）今日のところは他の本を物色。
そこで見つけたのが「Ｃ言語ポインタ完全制覇（前橋和弥 著）」という本です。
これが俺の心に大ヒット。
なんで配列の要素チェックをしてくれないのか、とかポインタにはアドレスが入るんならポインタに型なんてないんじゃないの？とか、過去に疑問に思って人に絡みまくった内容が並んでます。
また、とかく hairetsu[i] と書いていればポインタ使わずに済む、少なくとも今は使ってないと思っていた俺はショックを受け、即買いですた。
K&R2より安いし(笑)

あう・・・先日の日記で書いた fflush(stdin) はやってはいかんと書いてある・・・（-＿-；
確かにK&R2にも「入力ストリームに対してはその効果は不定」と明言されてるし、いろんなコンパイラの実装を確認した人によると効果はバラバラ。
ファイルからの入力もキーボード入力もフラッシュしてくれたりキーボードのみフラッシュしたり、gccはどちらも何もしないとのことなので先日からの俺のコードは動かん（てか勝手に動く）でしょうな・・・


先ほどの hairetsu[i] の件ですが、これは *( hairetsu + i ) の書き換えに過ぎず、すなわち俺はとっくにポインタ演算を行っていたわけです。
ｉ をインクリメントすることは見かけ上添え字を変えて配列の ｉ 番目の要素にアクセスしてるわけですが、その実、配列の先頭アドレスから ｉ ×配列の要素の型のサイズだけオフセットしたアドレスの値を読んでるようです。

いかん、どうにもこういう説明うまくいかんわ。

で、どうしても気になっていたのが *( hairetsu + i ) という加算です。
これがどうにも納得いかなくて試行錯誤しました。
だってこれ、単位が合ってないですよ。
char型だと何の問題も無いですが、これが4バイトの型の配列だったりした場合、hairetsu + 1 とした時の実際の番地は +4 されるわけです。
つまり、ポインタの演算において +1 の部分は整数ではなく、背後に sizeof(型) の乗算が隠されているということになります。
単位、合ってないでしょ？hairetsuの単位は[番地]。これは0を原点とする積算です。片や +1 の方の単位は[番地/型のサイズ] です。単位の違うものの加算など数学的に間違っている。
アドレスを整数演算して何が楽しい？と言われればその通りなんですが、大概の教本では「ポインタはアドレスを格納する」と書いてあります。
なのに取得したアドレスに対する演算には謎の（全然謎じゃないですが）係数が勝手に掛けられるのは気持ち悪いと思いませんか。

正直、ポインタの値を表示すると番地が表示されるという実装がいけない気がします。Cのポインタはあくまでもポイントするだけであってそれが番地であるとは書いてないんだから実際は番地で行っていたとしても隠蔽すべきだったんじゃないの？と。


次々出てくる謎。
第二弾は「なぜ文字定数はint型？」ですだ。

文字定数というのは、 a とか C とか、まぁCでは 'a' とか 'C' とかって書かなきゃいかんのかな？とにかくASCIIコードの１キャラ。
これをプログラマが格納しようとして変数を用意する場合、普通はchar型を用意すると思います。
だってASCIIコードは７bitしかないんだから１バイトで十分でしょ・・・

ところが、sizeof('a') の実行結果は（俺の環境では）４になります。
当然、sizeof(char) は１です。
この辺りのことは C FAQ の8.9に記載がありますが、実は文字定数はint型だそうです。
でも「実はそうなんです」と書いてあるのみで理由が書いてない。規格書を読まないとだめかな・・・
一応、CPUのレジスタのサイズがint型の基準なので、要するにそのサイズがそのCPUのアクセスの最小単位となるのでその辺の都合だと聞いたような気もしますが・・・いまだ納得できず。

それはそれとして似たような事例として、「getchar()の戻り値はint型」というのもあります。
例によってアカデミックな勉強で何も身につかなかった俺はいちいち関数一覧を開きながらコード書いてる（直接書いてるよ・・・）のですが、関数の引数と戻り値を確認していると・・・

　　int getchar()

ん・・・？なぜーにASCIIコード（１バイト）を返す関数なのにintで受けなきゃならんの・・・？
（まーホントのところ言っちゃうと char *strchr(const char *s, int c);の方で気づいたんだけど）
これがまた、現役でバリバリやってるソフト屋に 「なんで？」 って聞くと大概 「はぁ？んなわけねーべ！char返すに決まってんじゃん。いつもcharに代入して使うけど警告も出ないぜ」 と言われます。

多少調べると、その辺りに言及しているサイトは結構ある。たいていは「エラーとしてEOFを返すからだ」と書かれています。
EOFというのはヘッダで -1 と定義されてるから、char型では受けられない、とか書いてるんです。
いやアンサインドならわかるけど、普通のcharは-127まで受けられるべ。別にcharでいいじゃん・・・・

サインドの（符号付の）型の場合、最上位ビットはマイナスを表すビットになり正の数、負の数（２の補数で表現）それぞれ表現できるのは１ビット少なくなります。
（前述の通りASCIIコードはそもそも最上位ビットが無い７bitです）
そういう意味で「−１が受けられない」では説明不足だと思います。
だいたいエラーの時ってさー、キーボードからの入力がエラーってなんだよそれ！どうすれば発生するの？その時はすでにシステムが逝っちゃっててエラー処理どころじゃないんじゃないの？と思わんでも無いですな。

ところで、同様に文字取得の関数で

int fgetc()

というのがあったのでこれで実験してみました。
いろいろファイルを読ませてみたところ、少なくとも俺の環境ではこの関数は１文字（１キャラ）読み出すのではなくて、１バイト読み出すことが分かりました。


どういうことか？


バイナリファイルを読ませたらどうなるか、つまりバイナリの0xFFを食わせてやれば２の補数ですからエラーでなく正常範囲で-1が返るということです。
これをcharで受けてしまうとエラーの -1 と弁別できません。
両者とも0xFFとなります。
一方int型で受けた場合は
データの-1 0x000000FF
エラーの-1 0xFFFFFFFF
となり弁別可能です。
こういうことでは無いかと思います。

が、この関数の用途を考えるとやはり文字取得がその本懐であり、ASCIIコードが返らない時点で（最上位ビットが立っている時点で）少なくとも１バイト文字ではないという判断をして別の処理へ回すようにすべきだとは思いますが。

まだ俺、２バイト文字には手を出してないわけですが、普段テキストと言ってるファイルも２バイト文字使ってるならC的にはバイナリファイルですよね・・・・。

あーうー何かヤな雰囲気に。
MSを擁護したくはないけど知的財産云々という裁判はもううんざりだ。
結果として迷惑を被るのはユーザだぞ・・・
アプレットだプラグインだとかは俺カンケーないけどね。

ソーテック、キューブ型PC発売。何も変わってねぇなソーテック。
あの記事がなつかしいけど、ほんと懲りねぇやつらだな。

ところで、最近まともにプログラミングの実技をやってます。
実技ってオイオイ・・・。
実は会社で仕事関係で、必ずしも必要ではないがあったら便利なツール、というのを残業時間に作っていてそれをPCから駆動するための DOS アプリなんですYO。

これがまた、アカデミックに勉強したのは２年前？が最後。
その後pythonという言語をちょっと勉強し、プライベートで perl のスクリプトを量産。さらに仕事の効率化の為に VBA でマクロをいくつか書いたくらいですね。
というかですね、アカデミックな勉強というのは正直無駄の無駄無駄でした。だって覚えてないもん。
DOS窓でさ、入力した文字が表示されても「だから何？」って感じ。数値計算しようが何しようが、てか何が "Hello world."だよつまんねぇよ。
興味ももてないし、必要を感じないからポインタも構造体も身にならねぇ。
先日のROの文字化け検証の為に ASCII コード変換ツールを書いたけど、そういう目的が無いとですね。
スミスではないけど、すべては"目的"ですな。

そんなわけで今回は立派な目的有りです。
それもUSB経由でハードを駆動する。
画面に文字が表示されても面白くもなんともなかった。perlでcgi書いてブラウザでの表示が変わるのはちょっと面白かったけど、今回は物理世界で現実にモノが動く、ハード屋はやはりこれですよ！
これがなくては！

今さら本を読む気もしないし、仕事に使うツールなので時間が無い、記憶に頼りながら行き当たりばったりで書いていく。
時代が俺の背中を押してくれるのですよ。問題があったらググって出てきたコードをパクればいい。
そんなつぎはぎの、とりあえず動くコードを走らせながら実動作部分を削りだしていけばいいんですよ。
日曜プログラマなんだから。

・・・しかしやってみると挫折の連続でした。
驚愕の新事実の連続。

注記：大げさな書き方してますけど、初歩ですから。リアル初心者の言葉ですからそういう目でよろしく。

まずCには文字列の組み込み型が無いそうです。正直ビックリ。perlで気にせずにホイホイ文字列をぶち込んでs///とかやってたので、判定どころか代入すら自分で関数作って回さなくてはいけないショボさにしょんぼり。

次にCはバイナリを扱えないそうです。HEXは扱えるくせに、いざ8bitの入出力を直接いじろうとすると内部で２進で持てないのでポートごとの制御ができない。これも自分でヘキサ←→バイナリの相互変換関数を書かないとだめです。ビットシフトや論理演算はできるけれど、そもそも累乗の演算子すらない。
複素数とまで言わないけど、累乗くらいは使うだろ・・・とまたしょんぼり。

そして変数ごとにメモリを保護してくれないようです。
サイズの小さい型の変数に大きい型の変数を代入すると、余ったビットは切り捨てられるのかと思いきや無理矢理はみ出してでも上書きするようです。
実際にやってしまったのが配列のオーバーフロー。
char hairetsu[2];
と宣言していた配列に、後で hairetsu[2]='A'; などとしていたのです。
結果この配列の後ろにスタックされていた変数の値を書き換えてしまい暴走。宣言は配列の最後の要素を書くと信じていた俺は何が起こったかわからず、
（解らなければアクセスしてない変数が突如書き換わったように見えますよね）
また解析をお願いした先輩や嫁（プロのソフト屋）は、まさかそんな根本的な間違いをしてるとは思わなかったので苦戦しました(笑)
結局嫁さんが見つけてくれましたが・・・俺は別にFORTRANがそうだった（※）からとかいうわけじゃなくてただの思い込みだから言い訳もできませんですだ('A｀)

※・・・FORTRANでは hairetsu[2] と宣言した場合、確保される要素は１、２、になる。
この場合厳密には hairetsu[1:2] と宣言するが、開始値が１の場合は省略可能。つまり開始値は１がデフォルト。

てかさ、宣言してない要素に書き込もうとしたらエラーを吐くか、吐かずとも「書けないで終わる」で済む話じゃない。
変数単位で保護してくれないんだったら、これを前提に長さ変えて使えば極端な話、１つのプログラムには最大長の型の配列を１個宣言すれば済むじゃない。
後は自分で適当に上書きしていけばいいんだから。共用体なんて要らないんじゃないですかね。
ションボリック。

当たり前のようなところでも詰まる詰まる、プロンプトを出して一文字入力させ、その内容で分岐したかったんですが（普通ですよね）、getchar() で一文字読み込むのはいいとして、ループで再びそこに回ってくると勝手に進むんですよ。
なんじゃそりゃ、内容を吐かせてみると改行が入ってる。
入力ストリームから１キャラ分だけ取り出したため、改行コードが残ったままになっていると思われ、読むたびに fflush() で標準入力をフラッシュすることにしました。

注記：これはやってはいけないこと（というか効果を期待してはいけない偶然の結果）だと後で知ることになります。

結局のところ俺は困るまで突き進むタイプなので、たとえより便利な機能が存在しようとも今使える（知っている）機能を駆使して実現できる機能ならそれで代用してしまう傾向があります。
どうにもならない時になって初めて人に聞くと、その度に驚愕の新事実が！

たとえばRO文字化けのアレもバイト単位でASCIIコードを判定して 0x61 〜 0x7A だった場合は 0x20 減算するといった処理を自前で書いたわけだけど、実はtoupper()という関数がまったく同じことをしてくれるのでした。

文字列を扱えないという部分も悪戦苦闘を続け、最初はforループで１キャラクタずつコピーしていましたが、string.h に strcpy というポインタ経由で配列の任意の場所に代入できる関数を発見。
誰か先に教えてよ〜。(；´Д⊂

これで行けるとばかりに文字列編集部分を関数に切り分け、ポインタ渡しポインタ返しでばっちり・・・と頑張っていたところに stdio.h に sprintf() を発見・・・
こっちで充分じゃないですか・・・。
こんなんばっか。

９月に入ってるのに日記のページを切り分けない理由と言うのは、単に８月末の日記も同時に更新していてそれがUPされていきなり過去ﾛｸﾞ落ちになるのが寂しいからです。
が、これをやってしまうと（いずれ切り分けるので）キャッシュやブックマークとの齟齬が生じてしまい、かつて大々的に振りかざした大義名分が空々しく聞こえてしまうのが悲しい。

それはそれとしてですな、これはいかがでしょうか。

「デジタル万引きについて」

NEPRO JAPAN という会社が行ったアンケートにより、デジタル万引きという言葉を知っているユーザは半数以下だが 「コアユーザの大半が良識を持っていることが分かった」 んだそうです。
以下、設問については引用します（語尾など原文まま）。

設問１．「デジタル万引き」って言葉知ってる？
設問２．「デジタル万引き」って書籍や雑誌の自分の欲しい情報だけを携帯カメラで写すことだけど、そういう行為をしたことある？もしくは、やったことはないけどやろうと思ったことはある？
設問３．「デジタル万引き」についてどう思う？犯罪？よくない事？別にいい？

・・・
解りますか、この恣意的な質問の順序。
正直、そんな単語は知らないです。今も知りません。誰がどこでどう定義したもので、どういう意味でどの範囲で効力を持つものかまったく分かりませんです。
けど、知らないながらも「万引き」などと言われたら「別にいいんじゃない？」なんて言えるわけないでしょう。
設問から「デジタル万引き」という単語を抜き、設問２、３に限定していれば非常に有意義な結果が得られたと思います。 （設問４、５に関しては適切だと思いますので言及しません）

まぁ言ってしまえばこの会社、およびスポンサーにとっては適切な設問、かつ適切な回答を引き出したというところでしょう。
例によってこの調査会社の会社情報を見てみると、主要取引先はケータイのキャリアがずらり。事業としてもドコモ、ぁーぅー、Jぽん、塚等の販売代理店を運営しています。
お分かりですね？

およそ、利害関係の絡むスポンサー付きの研究は、それがいかに高度に学術的な内容であっても一次に信用できるものではありません。
うちの父親にグーでブチ殴られそうですが、製薬会社のスポンサー付きの研究で「安全」と結論されたとして、その結論以外の部分（よーするにデータです）を別の研究者に持ち込めば「クロ」と言われるかもしれません。
データから推論を得、推論に基づいた実験からデータを得るというそのどちらの過程においても研究者自身の恣意の影響が出ます。
殊更、スポンサー付きの場合は始める前から望ましい結論が存在するわけで、そんなものを鵜呑みにしてはいけません。

殊にこれは物理作用ではない、人の意識を抽出する作業ですからこんな設問で得られたデータ自体に意味など有りません。
どうせなら立ち読みという慣例自体を否定するとか、あるいは内容を知らずに対価を払うシステムを否定するとか、バシっと何か言えよ、というところ。
そもそも文章、映像、音楽、およそ良いも悪いも受け手次第といった性質を持つ商品の場合、買ってみたらカスだったということは往々にしてあるものです。
しかしながら、知らないこと、そこから知っていく過程、あるいは知ること自体に価値がある商品の場合、買う前に内容を判断することはできません。
なぜなら内容を知ってしまったとたんにその商品はその消費者にとって価値を失うからです。
前者は推理小説など、後者は情報誌などですね。

従って今回の設問１〜３は下記の通り置き換えて再度実験していただきたい。

「アンドロイドによる立ち読みは犯罪とすべきか。」

駄文失礼しました。