novus log

分享一個前幾天幫忙排除問題的趣事，事後看覺得再明顯不過，發生當時卻讓人困惑了一下。前幾天要下班時，發現同事還在奮戰，所以就過去湊一下熱鬧。原來是他正在為某個平台建立 cross-compile 環境時碰到麻煩。
這裡說明一下，我們團隊的「cross-compile 環境」其實就是一個個 chroot，預先裝好了目標平台的 cross-toolchain、程式庫，並設定好環境變數。通常這些 cross-compile 都是由熟悉 Linux 環境的人事先打包好，新加入者只要按照產品型號下載對應的編譯環境，就可以立即上手建置專案。當硬體廠商更新驅動程式、或者程式庫 推出安全性修正時，負責的同事必須要更新編譯環境，有時候重大的調整會需要整個砍掉重頭建起。

資料來源： http://drops.wooyun.org/news/8864
對岸有網友發現從某些非官方管道下載的 XCode 編譯器，會在編譯出來的 APP 中植入特殊的可執行碼。目前值入的可執行碼無害，只是會蒐集一些資訊回報給託管在 Amazon  的伺服器。但這可能只是試水溫的作品，未來很有可能會出現更強的應用。
目前被感染的 XCode 編譯器似乎是來自迅雷、百度等個人網路硬碟。按原文描述，散播該後門的人混跡於開發者社群當中，只要有機會就向人提供他自己網路硬碟上的「鏡像下載點」。例如當 XCode 官方發布新版本時，他也會好心的公告給社群中的人，並且提供下載位址。又或者有人詢問如何建立開發環境時，他也會藉機提供下載位置。
讓我覺得頗為驚訝的是，已知有若干大公司出品的 App 也中招，難道這些大公司的開發團隊或協力廠商不去官網下載 toolchain，反而使用陌生私人網路硬碟的二進制檔？
有一位網友提到一個耐人尋味的現象：「还是不能相信迅雷，我是把官网上的下载URL复制到迅雷里下载的，还是中招了。」如果這是真的，那麼對岸的網路硬碟服務就不是普通的恐怖。
我對 XCode 的 toolchain 完全不了解，不過看起來它是透過替換基礎程式庫的方式感染目標程式，這個方法相對簡單很多，影響層面也比較低。我的意思是，不至於像 Ken Thompson 示範的那樣在編譯階段改寫 AST，可以再傳染給用這個編譯器建置的編譯器。
以我比較熟悉的 GCC 來說，類似的做法大概是抽換靜態連結的 libgcc 或 crt。我以前做過類似的事，不過目的只是在於產出極小的二進制檔。技術不算難，難的是誘使其他人用你的 toolchain。現實中的 Linux distro 大都有固定的套件庫，或許 MinGW 比較有機會。
比較早的 GCC 做 AST 層次的改寫比較麻煩，近期的 GCC 已經支援 plugin，我想應該會簡單很多。

在程式中通常有若干種方法將資訊串成字串，一些可能的寫法如：
msg = format("Do you want to delete %s from %s?", user.name, group.name);

msg = "Do you want to delete {1} from {2}?".format(user.name, group.name);

msg = "Do you want to delete " + user.name + " from " + group.name + "?";

msg << "Do you want to delete " << user.name << " from " << group.name << "?";

前陣子在程式人雜誌參與了關於編譯器書籍的討論，我想說自己都打了一堆字，不如整理一下放上來。
講到編譯器書籍，很多人都會想起 Aho、Sethi、Ullman 和 Lam 的勇者鬥惡龍，這本書深度和廣度兼俱，所以被許多課程採用為教科書。但本書二版在 amazon 評價偏低，可見不符合許多人的期待。我認為每個人取向不同，不必妄想一本傳說中的經典就可以涵蓋理論與實務全面知識，而且對於學習者來說容不容易吸收也很重要。
我手邊有勇者鬥惡龍一和二版，我想一版就不必多說，這裡提供對二版的一些看法：

二版自出版以來，就因為錯誤甚多而受到批評，有些錯誤確實會影響理解，最好配 errata 讀。我手邊的國際英文版（封面沒有龍...囧）似乎已經 patch 完第一張 errata，但仍然有第二張 errata 的錯誤。如果買原文最好能取得最近幾刷，我不知道中譯者有沒有主動修正這些問題。
以一本現代編譯技術的教科書來說，介紹 SSA 的篇幅實在少得可憐 -- 只有一頁 -- 根本是放心酸的。
10、11 章講解指令層級平行化和迴圈平行化算是本書的一個亮點，但是我想普通讀者用不上。

程式碼用什麼格式儲存？還用問，當然是「純文字」囉。其實這個問題並不簡單，所謂的「純文字」可能是眾多編碼當中的一種：

「本地」使用的編碼：例如 Big5、GBK、Shift-JIS、ISO-8859-1,2,... 等等。Windows 下的編輯器常以此為預設。
UTF-8：一些 Linux 的編輯器可能以此為預設。
UTF-16、UTF32：這類編碼方式非常不適合用來儲存程式碼，這裡不討論。

前言
(未定稿，近期仍可能頻繁修改，歡迎提出各種建議，不論是技術方面或是文章描述方面)
在即將邁入 2013 年的今日、Unicode 已推出 6.2 版，Unicode 好像已經屬於沒什麼好介紹的基本常識了吧？其實，這篇文章某種程度上是為了「訂正」而寫的。如果我沒記錯的話，嗯，本文的第一個版本是在七年前寫的。說來挺不好意思的是，之前的版本在技術上從來就沒有完全正確過，雖然都不是很嚴重的錯誤。還好早期版本所發表的地方都相對短命，應該沒有誤導到太多人。
本文的目標很單純，只希望以後讀者遇到與文字編碼有關的選擇時，能夠清楚地知道自己在做什麼。因此我會從比較偏向實用的角度整理相關知識，而非專注於編碼的技術細節，畢竟大部分的人都沒有必要挽起袖子親手處理底層格式。

「C++ 是 context-free 嗎？」這是我在很長一段時間裡，分別在 stackoverflow.com 等許多地方都看過的問題。類似的問題還有其他變形，有時主角換成別的程式語言，或者變成「...是否為 context-sensitive」等等。
我發覺這類問題似乎具有某種雞同鴨講和鬼打牆的傾向，有些參與者沒有先釐清概念、用詞也不統一，以致於耗費大量篇幅卻難以觸及重點，反而顯示出許多人對於形式語言充滿誤解。我甚至看過一些人拿某某程式語言不是 context-free 做為不喜歡某某語言的理由，但是他很明顯沒有搞懂 context-free 的意義。
攤開 C++ 的規格書，裡面有一份詳盡的文法，其中每條 production rule 左邊都只有一個 non-terminal，所以是 context-free grammar (CFG)。這裡要注意的是「ISO C++ 規格書附的文法」並不是形式語言意義上「C++ 語言的生成文法」，因為「ISO 規格書附的文法」所生成的字串不保證滿足所有 C++ 語言規範。

最近一直沒時間寫新文章，所以貼篇舊聞。
Donald E. Knuth 是在大學時期打工才接觸到電腦，那個時候他剛好也在學校籃球隊幫忙。他紀錄了每位球員在不同位置的表現，並且在 IBM 650 主機上設計程式進行統計分析，以這些資料作為球員調度的依據。原本 Case Institute of Technology 在上年度只有贏得 6/16 場球賽，使用 Knuth 的方法後至少已經贏得 11/14 場球賽，後來成為聯賽冠軍。

可能有不少人在書上讀過這段故事，不過我最近看到這段影片，終於發現他們籃球隊以往戰績不佳的可能原因之一，如果只看書本文字介紹就無法發現這點。

最近在 trace 的程式碼當中讀到類似下列這樣的片段
TCHAR name[MAX_NAME];

...

::GetWindowText(hwnd, name, sizeof(name));

據統計，透過搜尋連結至本部落格最常用的關鍵字是某靈媒的名字，其次是某特異功能人士的名字，雖然我有點不爽但並不算太意外。
真正讓我意外的是，有人用「C 真亂數產生器」之類的關鍵字連過來，我猜是因為這篇文章的關係。我覺得意外的原因，是因為我以為這是已經是最基本的常識。
這裡鄭重告訴所有使用「C 真亂數產生器」之類的關鍵字找到本文的網友：