(1) 関数引数の const DWORD X[] のような記述はコンパイルエラーになる。 例：FatFsのf_fdisk関数
(2) f_fdiskを使わなくてもコンパイルエラーになってしまうので次のような対処をした。
#if defined(__PCH__)
FRESULT f_fdisk (FFBYTE pdrv, DWORD szt[], void* work); /* Divide a physical drive into some partitions */
#else
FRESULT f_fdisk (FFBYTE pdrv, const DWORD szt[], void* work); /* Divide a physical drive into some partitions (PCH compiles error) */
#endif
(1) 日本代理店のサイトにはCCSのコンパイラは関数ポインタを使えない、という情報がある。
(2) しかし、本家CCSのFAQはこの件に関してサンプルEX_QSORTを見よ、と言っている。関数qsortに比較関数を渡す例である。
(3) このサンプルもそうだが、関数ポインタを他の関数に渡す場合の記述法が要注意である。
(4) たとえばFatFsのf_forward関数。FatFsのオリジナルの記述は、
FRESULT f_forward (FIL* fp, UINT (*func)(const FFBYTE*,UINT), UINT btf, UINT* bf); /* Forward data to the stream */
だが、これだとコンパイルエラーになる。
(5) EX_QSORTの例に倣ってたとえば次の様に記述する。
#if defined(__PCH__)
typedef UINT (*_Fwdfun)(const FFBYTE * buff, UINT btf); /* f_forward callback function */
#endif
#if defined(__PCH__)
FRESULT f_forward (FIL* fp, _Fwdfun func, UINT btf, UINT* bf); /* Forward data to the stream */
#else
FRESULT f_forward (FIL* fp, UINT (*func)(const FFBYTE*,UINT), UINT btf, UINT* bf); /* Forward data to the stream (PCH compiles error) */
#endif
(6) 試してみたところ関数ポインタは機能しているようだ。
・#device ansi を指定しないとCの常識から離れる。指定したとしてもいろいろ思いがけないことがある。
・intは 8ビット
・shortは 1ビット（つまりBOOL用)
・分割コンパイルが出来ない (CCS C Compiler Manual に Multiple Compilation Units are only supported in the IDE compilers, PCW, PCWH, PCHWD and PCDIDE. とある。 つまりCCS社製のIDEならできるらしい。)
・関数の再帰呼び出しができない。これは仕方ないかもしれない。しかしマイコン用ファイルシステムFatFsのputc_bfd関数(ff.c)は再帰を利用していて、他のマイコンでは再帰が使えることは普通なのだろうか。
・外部変数であっても static指定しない限り 0 で初期化されない。
コンパイラとしての動作ではないが
・MPLAB X IDE v1.95 で使用中、"Parsing ソースファイル名" の表示が出たままフリーズしたことが何回かあり (XC8では記憶にない)
PIC用Cコンパイラを開発元(CCS Inc.)から直接購入した。
(1) 製品は「PCH Command-line C Compiler」
オプションとして
Programming/ Debugging Tool ... なし
Software Updates ... ３０日
Software CD-rom and Manual ... なし（つまりダウンロード版)
で、計$200.00である。
(2) 購入手続きでは「ショッピング用アカウント」を作らされたりするが、面倒は無かった様に思う。支払い手段はクレジットカードである。
(3) 他の方のレポートにもあるとおりダウンロード販売といえど完全に自動化されていない。日本時間で日曜日の午前に注文したが、ダウンロードの案内メールが来たのは月曜日の２２時４０分過ぎであった。
(4) ここで問題が発生。
ダウンロードしたファイルをインストールする際に、メールに添付されているファイル(registrationファイル)を使え、とのことだが、ファイルが添付されていない！？
(5) CCSのサポートに「添付ファイルが無いよ」と英語で書いてメールした（日本時間で深夜１時３０分ごろ）。
(6) それに対する回答が来たのは約２時間後（日本時間で３時２０分ごろ）であった。
それによると「もう一度送ったけど、それでもだめならメールのセキュリティ設定を確認して欲しい。 あるいは代わりのメールアドレスを送って欲しい」とのことである。
しかし再送されてきたメールにも添付ファイルが無い。
(7) 原因はこちらにあった。
メールソフトとしてジャストシステムのShuriken 2014を使っているのだが、これが添付ファイルの存在を認識していないのである。
プロバイダのサイトからメールの送受信をするサービスを使ってメールボックスを確認するとちゃんと添付ファイルが付いているのだ(最初のメールにも、再送されてきたメールにも)。そこからregistrationファイルをダウンロードできた。
(8) 以上、CCS社側には問題はないと思われます。
添付ファイルは拡張子CRGの小さなテキストファイルがZIP圧縮されているだけだが、これをなぜShurikenが認識しないのかが謎である。
以下、加筆2015/05/21
(9) クレジットカード会社からの利用明細に上がっていた。 換算レート１２１．２２円で、金額は２４，２４４円である。
国内代理店から買うと税別３０，０００円（税込みだと３２，４００円）なので、約８０００円のお得になります。
以下、加筆2015/05/27
(10) ダウンロード期限がまもなく来る、ということで最新版をダウンロードした。 1ヶ月前のCCS社からのメールにあったリンクからダウンロードできる。
V5.045からV5.046への超マイナーバージョンアップである。
仕事でひさびさにJavaScriptを使う機会が来た。
しかも本格的な業務アプリの仕事ということで、JavaScriptをゴリゴリ書かなければならない。
というわけでオライリー刊「JavaScript」(David Flanagan著)を買い直すことに。
１３年前の第３版に対して今は第６版になっている。版数だけでなく、本の厚さの変化にJavaScriptの位置づけの変化が如実に表れている気がします。
ページ数はほぼ倍増、しかし定価は４２００円のままなのが助かります。
最近（２月末以降）、いくつかの仕事の話が複数方面からあった。
ところがここに来てどれも立ち消えになりそうな雰囲気に．．．。
さすがに凹みますが、いつまでも落ち込んでいてはフリーランスは出来ません。
さて、しばらくご無沙汰している同業者に来週あたり行ってみようかな。
ひさびさ（約３年ぶり）の派遣仕事に先月から参加している。
プロジェクトの期間は１年とか言われていた。しかし派遣会社の社員では無いフリーランスにとって他の顧客を"お留守"にするわけにいかないので、一応３月末までにしてもらい、その後はそのときに考えることにしてもらった。
（大会社のエンドユーザ － ＩＴゼネコン － 中堅ソフトウエア会社 － ローカルソフトウエア会社 － 私、という下請け構造である。 ローカルソフトウエア会社は私の旧知の人たちがやっていることもあって、時々派遣の仕事の話が来る。）
ところが、今月になってエンドユーザはプロジェクトの大幅縮小に方向転換してしまった。その結果、多くの派遣技術者はお役ご免、ということに。私も「１月末まで」である。
当初の計画のままプロジェクトが進めば大勢の人員投入が必要になる、ということでＩＴゼネコン以下の各社は人集めに先走りすぎたのだろう。
プロジェクトの続行にお金がかかりすぎるとの見通しがついたところで大きな方針転換できるあたり、大会社といえど民間企業だな、感心はしたが。
その一方で、エンドユーザの大会社は製造業の分野で独特のノウハウを持っていると言われている会社ですけど、ソフトウエアプロジェクトの運営の不効率さはどこも似たり寄ったりだな、とも思いましたね。
フリーランスをしていると"生きた化石"と呼べるようなシステムのサポート仕事が持ち込まれてくることがある。
"生きた化石"システムとは。
開発されてから相当な年数が経過（たとえば１０年以上）したが、ユーザ自身は何も不満無く使ってきた。トラブルも発生しない。
そのような状態で年数が経過すると開発会社との縁は薄れ、ときに開発会社の当初の担当者も引き継ぎをすることなく消えていたりします。
ところがシステムは老朽化します。ソフトは良いとしてもハードは間違いなく老朽化してトラブルを引き起こすでしょう。
そうなるとだれも面倒を見ることが出来なくて、私のようなフリーランスに持ち込まれることになるわけです。
この土曜日（１４日）そのような仕事が持ち込まれたので行ってきました。車で１時間かけて田舎町まで。
社長宅の"離れ"が会社事務所という典型的な(?)中小企業という感じでした。
で、問題のシステムですが覚悟していたほどには古くありませんでした。２０００～２００１年ごろ開発されたようです。なんとOSは"Windows NT4"。
トラブルはやはりハード絡み（プリンタ）でしたが、無事解決できました。
以前、このようなサポート仕事がきっかけで新しい仕事に繋がったことがありましたが、今回は果たしてどうだろうか？
「ITエンジニアのための ハイプレッシャー下での対応術」を読んでいて、仕事上のつきあいのある人物から以前(５年ぐらい前だったか)聞いた話を思い出した。
その人物が勤めている会社で、ある男(SE?)が担当している物件の収拾がつかなくなり、挙げ句の果てに"心を病み"会社を休む羽目になった。復職してみると、薬の副作用なのか顔の相貌が変わってしまっていた...。
雑談の中で聞いた話なので詳しいことは全く不明な訳ですが、当時この話を聞いていくつか感想を持ちました。
(1) "逃げる"という選択は無かったのかな？ 知人によれば「家族がいると、それも難しいのかな？」。誉められた手段ではないけれど、最後の手段としてはあり得るかもしれません。
(2) 会社・上司は何していたのかな？ 「あれはどうなってんだ！」とハイプレッシャーをかけるばかりが管理ではないはずで、「これ以上は無理」と判断して手を打つのも重要な管理と思うのですが。
(1)(2)どちらにせよ、混乱物件を押しつけられた後継者にとってはいい迷惑かもしれませんが、ここでも会社・上司のフォローが重要になってきますね。
いま振り返ってみると「仕事の混乱が心の病をもたらした」と知人は理解していたわけですが、"心の病"が先にあって、その結果仕事が混乱に陥った可能性もあるわけで、その場合(1)の選択は無いかもしれません。
その後この話題について知人と話をしていないので、その後どうなったかは不明です。
気になっていた本「ITエンジニアのための ハイプレッシャー下での対応術」を読みました。Ａ５版１５０ページぐらいの小さい本で、イラストも多いので１日で読み通すことができます。
ハイプレッシャー対応における最大のヤマで難関は「誠意を持って謝罪する」ところでしょう(P51)。しかも、「その場しのぎ」(P14)で逃げることなく、「無理難題を請け負ってしまうことなく」（P37)、冷静さを保つ必要があります。
本文から例を挙げると
「１週間以内にバグを全部取り除いてくれ！」
「バグの問題で、大変ご迷惑をお掛けしており申し訳ございません」(P141)
「納期遅れは契約違反だ！ どうするつもりだ！」
「お怒りはごもっともです。私共も納期を守り、性能の良いシステムをご提供したいという思いは、お客様と同じでございます」(P142)
という具合に、顧客からの主張に正面から向き合うことは避けつつ、しかし反論することも避け、相手の感情を静めなければなりません。
もちろんハイプレッシャー状況に陥らないことが大切で、そのことにも触れられています（P95：ルールの設定と遵守、P132：仕様変更を減らすには）。とはいえ、この本は開発工程のメインストリームを解説する本ではありません。
私自身はフリーランスとして仕事をしているわけですが、大半の顧客は、そんな業者に仕様や性能や納期やについて厳しい要求をしても仕方がないと思っているのか、この本で述べられているようなハイプレッシャー状況となったことはありません。
しかし、他の(知り合いの)開発会社のメンバーとして顧客に向き合うことはあり、ハイプレッシャー状況に遭遇する可能性はあります。その場合、この本でも注意されているとおり、一人で抱え込むことは立場的にも避けなければなりません。
