Debian 的 64-bit time_t 計畫

在「Debian: 64-bit time_t transition in progress」這邊看到 Debian 的 mailing list 上的討論:「64-bit time_t transition in progress」,另外官方也有整理 wiki page:「64-bit time」。

因為技術上無法表示 2038/01/19 以後的時間,確定會 breaking ABI 將 time_t 從 32-bit 變成 64-bit,而現在要想辦法搞定 32-bit 平台上面可以處理這樣的改變:

The goal of this transition is to ensure that 32-bit architectures in trixie (whether they are currently release architectures, or out of archive, etc) will be capable of handling current and future timestamps referring to times beyond 2038.

離 2038/01/17 還有約 13 年多...

兩個 unsigned int 取平均值的方法

Hacker News Daily 上看到 Raymond Chen 在講怎麼對兩個 unsigned int 取平均值的方法:「On finding the average of two unsigned integers without overflow」,這篇裡面提到了不少有趣的歷史,另外 Hacker News 上的討論「Finding the average of two unsigned integers without overflow (microsoft.com)」也可以翻翻。

最直覺的解法會有 overflow 的問題:

unsigned average(unsigned a, unsigned b)
{
    return (a + b) / 2;
}

如果已知 a 與 b 的大小的話 (如同作者說的,蠻多時候都符合這個情況),可以用這個方法避免 integer overflow:

unsigned average(unsigned low, unsigned high)
{
    return low + (high - low) / 2;
}

另外還有個方法是有專利的 (「Calculating the average of two integer numbers rounded towards zero in a single instruction cycle」),雖然在 2016 年到期了,各除以二相加後,只有 ab 都是奇數的情況下需要補 1:

unsigned average(unsigned a, unsigned b)
{
    return (a / 2) + (b / 2) + (a & b & 1);
}

接下來的這個方法用 AND 與 XOR 搞事,其中的原理可以解釋成,相同的 bit 不動表示值不需要動,不同的 bit 表示降一位 (除以 2):

unsigned average(unsigned a, unsigned b)
{
    return (a & b) + (a ^ b) / 2;
}

最後是暴力解,用個比較大的 data type 搞定他:

unsigned average(unsigned a, unsigned b)
{
    // Suppose "unsigned" is a 32-bit type and
    // "unsigned long long" is a 64-bit type.
    return ((unsigned long long)a + b) / 2;
}

後面有很多 assembly 的妖魔鬼怪跑出來就不提了 XDDD

SQLite 目前在規劃的 Strict Table,以及我從來不知道原來可以這樣惡搞...

Hacker News Daily 上看到「STRICT Tables」這篇,在講 SQLite 目前在規劃 strict table,對應的討論可以參考「Strict Tables – Column type constraints in SQLite - Draft (sqlite.org)」這邊。

我在 draft 文件開頭看到這個驚人的事實:轉型失敗的時候會直接寫進去,不是錯誤或是 0 或是 NULL 之類的值 XDDD

For example, if a table column has a type of "INTEGER", then SQLite tries to convert anything inserted into that column into an integer. So an attempt to insert the string '123' results in an integer 123 being inserted. But if the content cannot be losslessly converted into an integer, for example if the input is 'xyz', then the original string is inserted instead. See the Datatypes In SQLite document for additional information.

實際上測試建了一個表格測試:

SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> CREATE TABLE a (id INTEGER PRIMARY KEY NOT NULL, col1 INTEGER);
sqlite> INSERT INTO a (id, col1) VALUES (1, 'a');
sqlite> SELECT * FROM a;
id          col1      
----------  ----------
1           a         

我果然跟 SQLite 不熟...

PuTTY 安全性問題 (CVE-2015-5309)

雖然很久沒用 PuTTY 了 (因為用 Ubuntu 很久了),不過很難得看到 PuTTY 有安全性問題。

PuTTY 官方發佈了安全性通報 CVE-2015-5309:「PuTTY vulnerability vuln-ech-overflow」:

Versions of PuTTY and pterm between 0.54 and 0.65 inclusive have a potentially memory-corrupting integer overflow in the handling of the ECH (erase characters) control sequence in the terminal emulator.

不過老問題還是沒解啊,透過 HTTPS (i.e. Certificate authority 架構) 雖然有很多問題,但至少還是個靠稽核制度而建立的安全信任機制,在沒有任何可信任環境下可以當作起點下仍然是最好的方案:「如何安全下載軟體...」。

MySQL 裡搜尋 CHAR/VARCHAR (String) 欄位時要注意的事情

MySQL 表格欄位是 CHAR 或 VARCHAR 時,寫搜尋條件要記得使用 string 格式,而非數字。意思是,要避免這種 SQL query:

SELECT * FROM foo WHERE `column_string` = 123456;

原因是即使 column_string 加上了 B-tree index,也無法利用這個 index 加速查詢。

原因是,除了最明確的 '123456' 會符合外,還有很多種 case 符合:

mysql> SELECT 123456 = '0123456';
+--------------------+
| 123456 = '0123456' |
+--------------------+
|                  1 |
+--------------------+
1 row in set (0.00 sec)

mysql> SELECT 123456 = ' 123456';
+--------------------+
| 123456 = ' 123456' |
+--------------------+
|                  1 |
+--------------------+
1 row in set (0.00 sec)

這使得 index 無用武之地。

但如果欄位本身是數字 (INT/BIGINT),搜尋時用字串反而沒關係:MySQL 會先把字串轉型為數字再比較,所以會用到 index。

總而言之:

  • 可以用 INT/BIGINT 時,不要用 CHAR/VARCHAR 儲存。
  • 使用 CHAR/VARCHAR 的欄位當搜尋條件時,要用字串形式當作搜尋條件。(除非你很清楚你在做什麼)

今天上場當救援投手時解掉的問題...

了解 C 語言的數字資料型態...

在「Deep C: Understanding the Design of C Integer Types」這篇文章裡面以 C99 為參考文件,說明 C 語言的資料型態 (尤其是數字的部份)。

裡面引用了規個書的文件,說明「為什麼」數字資料型態會長這樣:

To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine’s hardware does it rather than by a general abstract rule.

以 target machine 為主要考量的特性與 C 語言被認為是 portable assembly language 的想法還蠻同調的... (What is a portable assembly language?)

所以寫 Portable C code 的人會比較辛苦,需要查規格書的資料,確保各平台都能夠正確被編譯... 而到最後演變成沒什麼人在管 "portable" 這件事情,反正 Autotools 開下去針對不能跑的平台用不同的 code XD