pretty code

2019年6月6日 星期四

UEFI - flexible array member

為了研究 Boot Variable,在 header file 看到一個很特別的宣告,依稀記得之前有看過討論,查了一下,這個東西叫做 flexible array member,是 C99 新增的語法,目的是讓動態新增資料更方便﹝語法上﹞,故寫了一個小程式來驗證。

2019/06/10 更新
1. 「C99 6.7.2.1 Structure and union specifiers」提到 flexible array member 只允許在 structure 的最後一個元素,故 UEFI 的 EFI_LOAD_OPTION 應該是用了某種方式達到一個以上的未定義長度的 array,故並不是 standard 裡的 flexible array member。
2. 原文如下:「As a special case, the last element of a structure with more than one named member may
have an incomplete array type; this is called a flexible array member.」

#include <stdio.h>
#include <stdlib.h>

typedef struct Item {
    int length;
    // flexible array member
    int data[];
} Item;

int main(void)
{
    // this is decided dynamically.
    int realCount = 4;
    int realSize = realCount * sizeof(int);

    Item *p = (Item*)malloc(sizeof(Item) + realSize);
    p->length = realSize;

    // give values
    for (int i = 0; i < realCount; i++) {
        p->data[i] = i;
    }

    // check size
    printf("sizeof(Item) is %d \n", sizeof(Item));

    // check values
    for (int i = 0; i < realCount; i++) {
        printf("p->data[%d] = %d \n", i, p->data[i]);
    }

    free(p);
    system("pause");
    return 0;
}

執行結果

sizeof(Item) is 4
p->data[0] = 0
p->data[1] = 1
p->data[2] = 2
p->data[3] = 3

UEFI Boot Variable Format - Generic Device Path Node Structure


A Device Path is a series of generic Device Path nodes. The first Device Path node starts at byte offset zero of the Device Path. The next Device Path node starts at the end of the previous Device Path node. Therefore all nodes are byte-packed data structures that may appear on any byte boundary. All code references to device path notes must assume all fields are unaligned. Since every Device Path node contains a length field in a known place, it is possible to traverse Device Path nodes that are of an unknown type. There is no limit to the number, type, or sequence of nodes in a Device Path.


UEFI Application - include path

我們在寫 UEFI Application 時,一般都會放在 "UDKBase\AppPkg" 這個 package 裡面, "AppPkg.dec" 裡面已經很貼心的將 "MdePkg/Include" 加進 "[Includes]" 裡面,所以我們可以直接在 .c 裡面使用 "#include <Library/BaseLib.h>",讓 compiler 可以找到相關的宣告。

換句話說,在找某些不知道的函數時,可以直接來 "MdePkg/Include" 此目錄找,有機會可以找到 UEFI 已經寫好的函數,我們就不用自己寫了。

底下是一些常用到的 header file

#include <Library/UefiLib.h>
#include <Library/MemoryAllocationLib.h>
#include <Library/UefiRuntimeServicesTableLib.h>
#include <Library/PrintLib.h>
#include <Library/BaseLib.h>
#include <Library/DevicePathLib.h>

2019年6月5日 星期三

Code Complete 2 冷知識

之前去天瓏看到這本書,一直以為是作者又出了新版,終於在鬼打牆的查詢後,發現是同一本書,只是變成不同的出版社取得版權翻譯﹝學貫→博碩﹞。回想我當初買書已經是 2008 年的事了,往事真是不堪回首呀。

書名  軟體建構之道   CODE COMPLETE 2中文版: 軟體開發實務指南  
作者 Steve McConnell著; 譚永歸譯   Steve McConnell著; 金戈等譯
出版機構   學貫行銷 博碩文化
出版年月 96/07 107/11
ISBN 9789866800115 9789864341313

沒辦法,翻閱它已經是 10 年前的事了,還知道書架上有這本書就很屌了,想當初我還曾有過《Effective C++: 55 Specific Ways to Improve Your Programs and Designs, 3/e》買了 2 本的記錄XD

僅以此文獻給跟我一樣書太多,一直在懷疑到底是不是新書的人!

2019年6月3日 星期一

UEFI Boot Variable Format


https://github.com/tylpk1216/BootVar

Onyx Boox Note Lite 觸控測試備忘記錄

因為手上有四台電子書閱讀器,故每台分配到的使用時間不一,前一陣子在看安納金的書,故都使用 Nova Pro 居多。

昨天在 AlwaysKobo 引起的蝴蝶效應後,撕下貼在 Note Lite 上的保護貼,看完了艾兒莎以及崴爺的書前幾章後,我想我應該是確定了幾件事。

使用藍芽翻頁器沒有問題,那應該跟 Kobo App 無關吧?

買了 Kindle 以外的閱讀器後,感覺變得疑神疑鬼,總覺得出版社電子書有問題,不然就是 App 有問題,再不然就是文石 Android 開放系統調校有問題,這倒是我以前只用 Kindle 沒有想過的事。

目前憑感覺測出左下角綠圈的失敗機率假設是 Z,那紅框處的失敗機率大概就是 3Z ~ 5Z,但此時左上角的綠框卻又一切正常。我不知道觸控式螢幕的原理為何,但總感覺跟系統調校脫不了關係。不知道博閱或是 Hyread 的功力如何,但以我的認知,文石應該是其中的佼佼者吧?

我一定是被第一台電子書閱讀器 Kindle Paperwhite 3 寵壞了!以前看英文技術書都沒這麼多問題,我想這只能等到 Amazon 自己出 Android 開放式閱讀器或是文石將原始碼公開才有機會優化吧,畢竟 Open Source 社群的行動力與廠商不是同一個檔次。

2019年6月2日 星期日

AlwaysKobo 引起的蝴蝶效應

為了參與這次的優惠,選了幾本書,其中一本是艾兒莎的《窮忙世代的翻身準則》,好吧,我承認是先看到妹子封面才買的,但也是因為我對這個主題有興趣,不料卻引發了一連串的蝴蝶效應。

首先,該本書在翻頁時,文字會先莫名其妙的放大,停頓一下才翻頁,看了幾頁後,專注力很難不被打斷,但以我這幾個月的經驗來看,很難說問題是出在誰身上,可能是文石系統、Kobo App,甚至是電子書本身格式都是嫌犯!但我能掌控的也只有文石系統的更新,於是便大膽的更新到 2.1.2,沒想到問題依舊,再加上文石並沒有修復2.1.1 開啟 regal 以及 Google Play Book 閃爍的問題,不禁讓我心灰意冷的上床睡覺。

早上吃完早餐,正想使用久違的冰心訣,繼續跟艾兒莎的書奮戰到底,突然想到何不關掉文石優化選項試試?終於,正直與善良都回來了!

有了這個新發現後,乾脆試試各家 App 關掉文石優化選項會怎樣?感受較明顯的是 EPUB 字似乎變清楚了,翻頁速度似乎也變快了?清晰度感覺是很主觀的事,但速度倒是可以被量測,於是拿出了昨天在迪卡儂購買的碼錶,我才發現我錯怪讀墨了,正確來說是我錯怪各 App 了。

Google Play Book ~ 1.00
Readmoo App ~ 0.98
Kobo App ~ 0.92
Kindle App ~ 1.22

除了 Kindle 翻頁問題,不得不開啟優化選項外,其餘都是關閉優化,與之前量測結果比較來看,著實有不小的差異,我認為目前速度對我來說已經很棒了,足夠讓我沉浸在閱讀的世界中。

可惜的是,我也不能沒有優化選項,不然 PDF 的閱讀體驗在不調整對比下仍然是很糟糕,畢竟我在御三家也購買了一些 PDF,實在無法棄他們不顧,只好視情況使用它了。

既然都做了那麼多測試,乾脆順便驗證 Note Lite 有時點到沒反應的問題,一不做二不休的撕下之前貼的保護貼,費了九牛二虎之力才把它順利取下。

此時回頭想想,原本不是配合 Kobo 優惠才買書的嗎?怎麼又做了一堆驗證測試的事,美好的假期也就此泡湯。